Well... I must confess that I had some difficulty on the first understanding of what is proposed. But after the 4 reads, I saw that this "spaghetti" thing is more powerful than I could imagine! Please correct me if I'm no right: But it looks like a "crypto sign and publishes" anything related to an organization. Yes, I think that with some effort CrossConnect LOAs can be fitted inside of it... I'm not sure if it is the better solution for the scope of LOAs, but certainly is a valid discussion. What is bubbling in my mind is the standard data model for each type of different attribute that can exist... Who will define that? Em seg., 22 de fev. de 2021 às 12:26, Christopher Morrow < morrowc.lists@gmail.com> escreveu:

On Mon, Feb 22, 2021 at 9:19 AM Douglas Fischer <fischerdouglas@gmail.com> wrote:

...

I believe that almost everyone in here knows that LOAs for Cross

Connects in Datacenters and Telecom Rooms can be a pain...

...

I don't know if I'm suggesting something that already exists. Or even if I'm suggesting something that could be unpopular for some

reason.

...

But every time I need to deal with some Cross-Connect LOA, and mostly

when we face some rework on data mistakes, I dream with a "PeeringDB for Cross Connects".

...

are you asking about something like this: https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/

Which COULD be used to, as an AS holder: "sign something to be sent between you and the colo and your intended peer"

that you could sign (with your rpki stuffs) and your peer could also sign with their 'rpki stuffs', and which the colo provider could automatically validate and action upon final signature(s) received.

...

So, this mail is a question and also a suggestion.

There is something like an "online notary's office" exclusive for Cross-Connect LOAs? - Somewhere Organizations can register information authorizing connections of Port on their Places (Cages, Racks, etc)...

The RPKI data today doesn't contain information about cages/ports/patch-panels, so possibly the spaghetti draft isn't a terrific fit?

...

If it doesn't exist. What would be necessary for that? Mostly considering the PeeringDB work model. - OpenSource. - Free access to the tool, and sponsors to keep the project alive. - API driven, with some Web-gui. And considering some data-modeling. - Most of the data being Open/Public (Organizations, Facilities(Datacenters and/or Telecom-Rooms), Presence on Facilities, etc). - Access control to Information that can not be public (A-side organization, Z-Side Organization, PathPanel/Port). And some workflow - Cross Connect Requiremento/Authorization from A-Side - Acceptance/Authorization from Z-side. - Acceptance/Authorization from Facilities involved (could be more than one) - Execution/Activation notice from Facilities.

-- Douglas Fernando Fischer Engº de Controle e Automação

-- Douglas Fernando Fischer Engº de Controle e Automação

Really, does anyone here think that it is good form to send email with font size *SMALL*? If your MUA does this by default complain to the developers. The default should be “medium”. If the font is too big on your screen change the magnification *you* choose to display to *yourself*, don’t change the font size you send to everyone else. Mark <div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:courier = new,monospace;font-size:small">Well... I must confess that I had some diffi= culty=C2=A0on the first understanding=C2=A0of what is proposed.<br><br>But =

On 23 Feb 2021, at 04:03, Douglas Fischer <fischerdouglas@gmail.com> wrote:

Well... I must confess that I had some difficulty on the first understanding of what is proposed.

But after the 4 reads, I saw that this "spaghetti" thing is more powerful than I could imagine!

Please correct me if I'm no right: But it looks like a "crypto sign and publishes" anything related to an organization.

Yes, I think that with some effort CrossConnect LOAs can be fitted inside of it... I'm not sure if it is the better solution for the scope of LOAs, but certainly is a valid discussion.

What is bubbling in my mind is the standard data model for each type of different attribute that can exist... Who will define that?

Em seg., 22 de fev. de 2021 às 12:26, Christopher Morrow <morrowc.lists@gmail.com> escreveu: On Mon, Feb 22, 2021 at 9:19 AM Douglas Fischer <fischerdouglas@gmail.com> wrote:

...

I believe that almost everyone in here knows that LOAs for Cross Connects in Datacenters and Telecom Rooms can be a pain...

I don't know if I'm suggesting something that already exists. Or even if I'm suggesting something that could be unpopular for some reason.

But every time I need to deal with some Cross-Connect LOA, and mostly when we face some rework on data mistakes, I dream with a "PeeringDB for Cross Connects".

are you asking about something like this: https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/

Which COULD be used to, as an AS holder: "sign something to be sent between you and the colo and your intended peer"

that you could sign (with your rpki stuffs) and your peer could also sign with their 'rpki stuffs', and which the colo provider could automatically validate and action upon final signature(s) received.

...

So, this mail is a question and also a suggestion.

There is something like an "online notary's office" exclusive for Cross-Connect LOAs? - Somewhere Organizations can register information authorizing connections of Port on their Places (Cages, Racks, etc)...

The RPKI data today doesn't contain information about cages/ports/patch-panels, so possibly the spaghetti draft isn't a terrific fit?

...

If it doesn't exist. What would be necessary for that? Mostly considering the PeeringDB work model. - OpenSource. - Free access to the tool, and sponsors to keep the project alive. - API driven, with some Web-gui. And considering some data-modeling. - Most of the data being Open/Public (Organizations, Facilities(Datacenters and/or Telecom-Rooms), Presence on Facilities, etc). - Access control to Information that can not be public (A-side organization, Z-Side Organization, PathPanel/Port). And some workflow - Cross Connect Requiremento/Authorization from A-Side - Acceptance/Authorization from Z-side. - Acceptance/Authorization from Facilities involved (could be more than one) - Execution/Activation notice from Facilities.

-- Douglas Fernando Fischer Engº de Controle e Automação

-- Douglas Fernando Fischer Engº de Controle e Automação

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Hmmm... I Don't know why this is happening. Considering my default set-up on the Gmail interface is defined to use Normal size. https://pasteboard.co/JPG2ZoK.png In fact, I had not even realized that this mail-list forwarded emails in the exact format they were generated. Usually, they set mailman to convert everything to pure-text. But thank you Mama for teaching me good manners. I will try to behave better, a search how to fix the size... P.S.: If you cloud help-me to fix that on Gmail, I can show you the Zoom Function on the Browsers or mail readers. Em seg., 22 de fev. de 2021 às 21:40, Mark Andrews <marka@isc.org> escreveu:

Really, does anyone here think that it is good form to send email with font size *SMALL*? If your MUA does this by default complain to the developers. The default should be “medium”. If the font is too big on your screen change the magnification *you* choose to display to *yourself*, don’t change the font size you send to everyone else.

Mark

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:courier = new,monospace;font-size:small">Well... I must confess that I had some diffi= culty=C2=A0on the first understanding=C2=A0of what is proposed.<br><br>But =

...

On 23 Feb 2021, at 04:03, Douglas Fischer <fischerdouglas@gmail.com> wrote:

Well... I must confess that I had some difficulty on the first understanding of what is proposed.

But after the 4 reads, I saw that this "spaghetti" thing is more powerful than I could imagine!

Please correct me if I'm no right: But it looks like a "crypto sign and publishes" anything related to an organization.

Yes, I think that with some effort CrossConnect LOAs can be fitted inside of it... I'm not sure if it is the better solution for the scope of LOAs, but certainly is a valid discussion.

What is bubbling in my mind is the standard data model for each type of different attribute that can exist... Who will define that?

Em seg., 22 de fev. de 2021 às 12:26, Christopher Morrow < morrowc.lists@gmail.com> escreveu: On Mon, Feb 22, 2021 at 9:19 AM Douglas Fischer <fischerdouglas@gmail.com> wrote:

...

I believe that almost everyone in here knows that LOAs for Cross

Connects in Datacenters and Telecom Rooms can be a pain...

...

I don't know if I'm suggesting something that already exists. Or even if I'm suggesting something that could be unpopular for some

reason.

...

But every time I need to deal with some Cross-Connect LOA, and mostly

when we face some rework on data mistakes, I dream with a "PeeringDB for Cross Connects".

...

are you asking about something like this: https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/

Which COULD be used to, as an AS holder: "sign something to be sent between you and the colo and your intended peer"

that you could sign (with your rpki stuffs) and your peer could also sign with their 'rpki stuffs', and which the colo provider could automatically validate and action upon final signature(s) received.

...

So, this mail is a question and also a suggestion.

There is something like an "online notary's office" exclusive for Cross-Connect LOAs? - Somewhere Organizations can register information authorizing connections of Port on their Places (Cages, Racks, etc)...

The RPKI data today doesn't contain information about cages/ports/patch-panels, so possibly the spaghetti draft isn't a terrific fit?

...

If it doesn't exist. What would be necessary for that? Mostly considering the PeeringDB work model. - OpenSource. - Free access to the tool, and sponsors to keep the project alive. - API driven, with some Web-gui. And considering some data-modeling. - Most of the data being Open/Public (Organizations, Facilities(Datacenters and/or Telecom-Rooms), Presence on Facilities, etc). - Access control to Information that can not be public (A-side organization, Z-Side Organization, PathPanel/Port). And some workflow - Cross Connect Requiremento/Authorization from A-Side - Acceptance/Authorization from Z-side. - Acceptance/Authorization from Facilities involved (could be more than one) - Execution/Activation notice from Facilities.

-- Douglas Fernando Fischer Engº de Controle e Automação

-- Douglas Fernando Fischer Engº de Controle e Automação

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

-- Douglas Fernando Fischer Engº de Controle e Automação

On Mon, Feb 22, 2021 at 1:39 PM Randy Bush <randy@psg.com> wrote:

...

are you asking about something like this: https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/

Which COULD be used to, as an AS holder: "sign something to be sent between you and the colo and your intended peer"

that you could sign (with your rpki stuffs) and your peer could also sign with their 'rpki stuffs', and which the colo provider could automatically validate and action upon final signature(s) received.

chris,

way back, the rirs were very insistant that their use of rpki authority was most emphatically not to be considered an identity service. this permeated the design; e.g., organization names were specifically forbidden in certificate CN, Subject Alternative Name, etc.

yup, I agree... though the b2b stuff George/Geoff have written up LOOKS like it could be useful for this LOA type discussion. The spaghetti draft appears to also fill this niche... Neither are particularly rooted in the RPKI except that the CA certs are being used as a method to attest that a 'thing' exists, and that something signed that 'thing' as proof of knowledge (I guess, really). Effectively this is: 1) I am 'ca-foo' in a tree that you can trust knows I am 'foo'. 2) I signed this blob (LOA) 3) I asked jane at bar.com to sign as well 4) you can verify me (because rpki tree) and you can verify Jane because she's also using her RPKI ca cert. this may be a little cumbersome to sort through, especially if all parties here aren't party to the RPKI (did equinix plumb the RPKI into their customer portal and all of the things required to make a x-connect work in this manner?), but I imagine that if this gets wings it could be automated and it could be reliable and all parties (except the colo folks perhaps?) may already have incentives in places to use their RPKI goop for this function. -chris

aside: of course a few rirs thought that *their* names should be in their certs as exeptions. i remember the laughter.

randy

--- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header mangling

On Mon, Feb 22, 2021 at 2:06 PM Randy Bush <randy@psg.com> wrote:

...

...

way back, the rirs were very insistant that their use of rpki authority was most emphatically not to be considered an identity service. this permeated the design; e.g., organization names were specifically forbidden in certificate CN, Subject Alternative Name, etc.

yup, I agree... though the b2b stuff George/Geoff have written up LOOKS like it could be useful for this LOA type discussion. The spaghetti draft appears to also fill this niche...

Neither are particularly rooted in the RPKI except that the CA certs are being used as a method to attest that a 'thing' exists, and that something signed that 'thing' as proof of knowledge (I guess, really). Effectively this is: 1) I am 'ca-foo' in a tree that you can trust knows I am 'foo'. 2) I signed this blob (LOA) 3) I asked jane at bar.com to sign as well 4) you can verify me (because rpki tree) and you can verify Jane because she's also using her RPKI ca cert.

this may be a little cumbersome to sort through, especially if all parties here aren't party to the RPKI (did equinix plumb the RPKI into their customer portal and all of the things required to make a x-connect work in this manner?), but I imagine that if this gets wings it could be automated and it could be reliable and all parties (except the colo folks perhaps?) may already have incentives in places to use their RPKI goop for this function.

this would work only if the LOA is being sent to someone with whom my contract is signed with a key validating through the same hierarchy, or the credential was associated contractually. i do not think equinix is up to this yet.

I agree that 'today' equinix (or the notional other Colo/etc folk) are unlikely to be able to make this work. In the future though, if the colo's customers are RPKI users, and the colo has some (probably) relatively simple code in hand they could perform verifications of this sort. I guess I didn't ask: "Do you want this to work 'now'? or is '2 to 5 yrs acceptable'?" :) Of course any new thing must be better than the world-of-faxes we live in today for this solution space, and it has to be adotable by the parties involved. -chris

On Mon, Feb 22, 2021 at 2:44 PM Douglas Fischer <fischerdouglas@gmail.com> wrote:

What if PeeringDB would be the CA for the Facilities? Supposedly this solves the CA problem of the "Colo Folks".

I think pushing your security identification out (as the notional equinix) to a third party where you can't revoke/change/etc is asking for dangerous things to happen. The 'strength' of the RPKI (vs the web-pki) is that there are a defined number of ways into the system. You have ip space (IP Number Assets)? you get CA-cert and can create ROA. there are surely a host of corner cases with 'use the rpki to sign not INR things!!!', but at least: "Are you sure that's the right foo.bar? not f00.bar? or fOO.bar?" "yes, they have a CA cert signed by the RIR, with INRs they can toggle ROA for.. if that CA cert signed the checklist then 'ok'" again, that draft is a... draft still and I"m sure we'll have a bunch of chatter/discussion/changes before done, but it smells like it might help.

Would PeeringDB be interested in that?

Em seg., 22 de fev. de 2021 às 16:04, Christopher Morrow <morrowc.lists@gmail.com> escreveu:

...

On Mon, Feb 22, 2021 at 1:39 PM Randy Bush <randy@psg.com> wrote:

...

...

are you asking about something like this: https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/

Which COULD be used to, as an AS holder: "sign something to be sent between you and the colo and your intended peer"

that you could sign (with your rpki stuffs) and your peer could also sign with their 'rpki stuffs', and which the colo provider could automatically validate and action upon final signature(s) received.

chris,

way back, the rirs were very insistant that their use of rpki authority was most emphatically not to be considered an identity service. this permeated the design; e.g., organization names were specifically forbidden in certificate CN, Subject Alternative Name, etc.

yup, I agree... though the b2b stuff George/Geoff have written up LOOKS like it could be useful for this LOA type discussion. The spaghetti draft appears to also fill this niche...

Neither are particularly rooted in the RPKI except that the CA certs are being used as a method to attest that a 'thing' exists, and that something signed that 'thing' as proof of knowledge (I guess, really). Effectively this is: 1) I am 'ca-foo' in a tree that you can trust knows I am 'foo'. 2) I signed this blob (LOA) 3) I asked jane at bar.com to sign as well 4) you can verify me (because rpki tree) and you can verify Jane because she's also using her RPKI ca cert.

this may be a little cumbersome to sort through, especially if all parties here aren't party to the RPKI (did equinix plumb the RPKI into their customer portal and all of the things required to make a x-connect work in this manner?), but I imagine that if this gets wings it could be automated and it could be reliable and all parties (except the colo folks perhaps?) may already have incentives in places to use their RPKI goop for this function.

-chris

...

aside: of course a few rirs thought that *their* names should be in their certs as exeptions. i remember the laughter.

randy

--- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header mangling

-- Douglas Fernando Fischer Engº de Controle e Automação

The LOA type model is one of the ones we showed on slideware when we presented RTA in IETF, and at the CloudFlare RPKI workshop years ago. The detached signature model inherent in RTA and RSC goes to "you define the business logic" It's not proscriptive. I saw nothing proposed here which I thought wasn't a rational thing to try and certify in this manner. The key point is, the "action" you want to approve has to vest in "who controls the stated internet number resources" -If they have no bearing, then its not rational to propose using (R)PKI to do it. some other PKI? sure. Randy is correct that the processes are baroque, not well defined, come with all kinds of corner cases: what does a more specific command (regarding some IP address) if its not signed and the parent is? or, if the more specific is, and the parent isn't?) Randy is also correct that RPKI certificates by design, do not permit their use in ways which go directly to things like identity proofs. detached signatures open the door to doing some things here, because you can sign over something which ways "the person identified by the following public key is to be permitted to ..." And in like sense, we removed the uses which go to message encryption, sender or receiver. You can't directly use an RPKI certificate to do "for your eyes only" -it can only say "the person controlling these numbers, says the following" Obviously, I think this detached signature model is good :-) On Tue, Feb 23, 2021 at 6:31 AM Randy Bush <randy@psg.com> wrote:

...

...

What if PeeringDB would be the CA for the Facilities? Supposedly this solves the CA problem of the "Colo Folks".

I think pushing your security identification out (as the notional equinix) to a third party where you can't revoke/change/etc is asking for dangerous things to happen.

there are a few examples of industry associations with simple, strong, and formal ties sufficient to allow forms of trust automation. folk such as karen o'donoghue, lucy lynch, and heather flanagan would be able to speak vastly more knowledgeably in this space than i.

...

again, that draft is a... draft still and I"m sure we'll have a bunch of chatter/discussion/changes before done, but it smells like it might help.

you might notice that we use it in draft-ietf-opsawg-finding-geofeeds. but that application is specifically to use rpki data to attest to ip address ownership. the problem there is that the draft is a cool proof of concept, but is not operationally easy to use.

randy

--- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header mangling

On Mon, Feb 22, 2021 at 8:50 PM Randy Bush <randy@psg.com> wrote:

...

you can sign over something which ways "the person identified by the following public key is to be permitted to ..."

you mean the fraudlent attacker who owned that INR seems to have signed this request for a €1.000.000,49 wire transfer to their iban. a person is not identified by that signature.

If someone has a valid CA cert/key from the RIR, it's very hard to argue 'fraudulent'. It's, however, "easy" for the RIR to reverse the error, right? :)