Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
[ side comment best ignored ] >> otoh, private AS numbers are used in non-confed topologies, e.g. the bgp >> stub customer who uses a private AS. they should not sign of course. >> but once i receive their announcement and strip the private AS, >> can/should i sign? i just looked at bgpsec-protocol and found no >> guidance. > > from that vantage point you are the origin. it's not clear to me that a > customer relationship is substantively then if you do this internal to ^ different [ i presume ] > your org. operationally the'yre probably also registering route objects, > issuing LOAS and operating on behalf of the private ASN. i buy everything but the LOAs. issues of legal authority to enter into contracts et alia. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
>> otoh, private AS numbers are used in non-confed topologies, e.g. the bgp >> stub customer who uses a private AS. they should not sign of course. >> but once i receive their announcement and strip the private AS, >> can/should i sign? i just looked at bgpsec-protocol and found no >> guidance. > > from that vantage point you are the origin. it's not clear to me that > a customer relationship is substantively then if you do this internal ^ did you drop "different?" > to your org. operationally the'yre probably also registering route > objects, issuing LOAS and operating on behalf of the private ASN. almost. while they _may_ be registering route objects, it is unlikely they are signing contracts on behalf of the customer. different transit providers provision customers using private ASs in different ways (doh). but i think essentially we are in agreement. as far as bgpsec and roa-based origin validation go, it would probably be good to specify how the transit operator proxies for the private AS customer. but this is the ietf. i have faith that someone can come up with a corner case where this should not be done. :) randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
On 12/7/16 1:07 PM, Randy Bush wrote: > otoh, private AS numbers are used in non-confed topologies, e.g. the bgp > stub customer who uses a private AS. they should not sign of course. > but once i receive their announcement and strip the private AS, > can/should i sign? i just looked at bgpsec-protocol and found no > guidance. from that vantage point you are the origin. it's not clear to me that a customer relationship is substantively then if you do this internal to your org. operationally the'yre probably also registering route objects, issuing LOAS and operating on behalf of the private ASN. > randy > > ___ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > signature.asc Description: OpenPGP digital signature ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
Yes, I agree. I just sent a message to the authors of the protocol spec (cc’d the WG) along the same lines. On 12/9/16, 7:57 PM, "Randy Bush" mailto:ra...@psg.com>> wrote: first the protocol spec needs to make clear if the real AS can proxy sign for a connected private AS. then i can hack the ops doc. seems to me that, as the real AS is required to strip the private AS from the path, the real AS should be able to proxy sign. but then who has the cert to create the roa, etc.? ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
> Yes, there should be something about private ASNs in the protocol spec. > > It would be nice to also see some operational guidance in this document. > > Alvaro. > > otoh, private AS numbers are used in non-confed topologies, e.g. the bgp > stub customer who uses a private AS. they should not sign of course. > but once i receive their announcement and strip the private AS, > can/should i sign? i just looked at bgpsec-protocol and found no > guidance. first the protocol spec needs to make clear if the real AS can proxy sign for a connected private AS. then i can hack the ops doc. seems to me that, as the real AS is required to strip the private AS from the path, the real AS should be able to proxy sign. but then who has the cert to create the roa, etc.? randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
Hi! Yes, there should be something about private ASNs in the protocol spec. It would be nice to also see some operational guidance in this document. Alvaro. On 12/7/16, 7:07 PM, "Randy Bush" mailto:ra...@psg.com>> wrote: otoh, private AS numbers are used in non-confed topologies, e.g. the bgp stub customer who uses a private AS. they should not sign of course. but once i receive their announcement and strip the private AS, can/should i sign? i just looked at bgpsec-protocol and found no guidance. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
otoh, private AS numbers are used in non-confed topologies, e.g. the bgp stub customer who uses a private AS. they should not sign of course. but once i receive their announcement and strip the private AS, can/should i sign? i just looked at bgpsec-protocol and found no guidance. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
> M4. Still in Section 7: “To prevent exposure of the internals of BGP > Confederations [RFC5065], a BGPsec speaker which is a Member-AS of a > Confederation MUST NOT sign updates sent to another Member-AS of the > same Confederation.” This is another case where the BGPSec spec says > something different: Section 4.3. (Processing Instructions for > Confederation Members) presents a mandatory mechanism that includes > signing, but not necessarily validating. BTW, if the updates are not > signed, then the signed path would be broken, even if all the routers > in the path support BGPSec, right? Is that the recommendation? > > it is common for a bgp confederation to include private ASs for which > there can be no unique authorative router credentials in the rpki. > hence i am suspicious of the protocol spec. i recant. the protocol spec 4.3 says the intra-confed path elements are stripped before exporting outside the confed. To prevent exposure of the internals of BGP Confederations [RFC5065], a BGPsec speaker exporting to a non-member removes all intra- confederation Secure_Path segments. Therefore signing within the confederation will not cause external confusion even if non-unique private ASs are used. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
alvaro, > In thinking about this point some more…what about > draft-ietf-sidr-slurm? Isn’t that supposed to address the private > space? > > M4. Still in Section 7: “To prevent exposure of the internals of BGP > Confederations [RFC5065], a BGPsec speaker which is a Member-AS of a > Confederation MUST NOT sign updates sent to another Member-AS of the > same Confederation.” This is another case where the BGPSec spec says > something different: Section 4.3. (Processing Instructions for > Confederation Members) presents a mandatory mechanism that includes > signing, but not necessarily validating. BTW, if the updates are not > signed, then the signed path would be broken, even if all the routers > in the path support BGPSec, right? Is that the recommendation? > > it is common for a bgp confederation to include private ASs for which > there can be no unique authorative router credentials in the rpki. > hence i am suspicious of the protocol spec. if a private-as router in confederation C signs from that as, others in the confed C may (or may not) have the slurmy data. but assuredly, when that route finally makes its way out to the global internet, there will be a signature in the path which no one can validate. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
Randy: Hi! In thinking about this point some more…what about draft-ietf-sidr-slurm? Isn’t that supposed to address the private space? Thanks! Alvaro. On 12/2/16, 12:56 PM, "Randy Bush" mailto:ra...@psg.com>> wrote: M4. Still in Section 7: “To prevent exposure of the internals of BGP Confederations [RFC5065], a BGPsec speaker which is a Member-AS of a Confederation MUST NOT sign updates sent to another Member-AS of the same Confederation.” This is another case where the BGPSec spec says something different: Section 4.3. (Processing Instructions for Confederation Members) presents a mandatory mechanism that includes signing, but not necessarily validating. BTW, if the updates are not signed, then the signed path would be broken, even if all the routers in the path support BGPSec, right? Is that the recommendation? it is common for a bgp confederation to include private ASs for which there can be no unique authorative router credentials in the rpki. hence i am suspicious of the protocol spec. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
unless someone screams As BGPsec will be rolled out over years and does not allow for intermediate non-signing edge routers, coverage will be spotty for a long time. This presents a dilemma; should a router evaluating an inbound BGPsec_Path as Not Valid be very strict and discard it? On the other hand, it might be the only path to that prefix, and a very low local-preference would cause it to be used and propagated only if there was no alternative. Either choice is reasonable, but we recommend dropping because of the next point. Operators should be aware that accepting Not Valid announcements, no matter the local preference, will often be the equivalent of treating them as fully Valid. Local preference affects only routes to the same set of destinations. Consider having a Valid announcement from neighbor V for prefix 10.0.0.0/16 and an Not Valid announcement for 10.0.666.0/24 from neighbor I. If local policy on the router is not configured to discard the Not Valid announcement from I, then longest match forwarding will send packets to neighbor I no matter the value of local preference. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
> “naggumite” – it took me a while to figure this out… ;-) one of the times jon postel and i disagreed. imiho being liberal in what you except is the road to entropic death. > My biggest problem with the original text is the normative “SHOULD > NOT”, so changing that to “might not” works for me as you’re > describing a fact of what may happen in the initial deployments… > > I am also happy to take the blame for dropping invalid stuff. ;-) this is the bit i wanna tweak when i get off the phone with untied randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
sig. wrong docco. will push this one. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
I'll wait to push when until have heard from the protocol editors. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
On 12/2/16, 10:56 AM, "Randy Bush" wrote: Randy: Hi! I’m fine with your comments, proposed text. Just a couple of more replies below. Thanks! Alvaro. … > > M2. In Section 7. (Routing Policy): “As BGPsec will be rolled out > > over…a long time. Hence a normal operator's policy SHOULD NOT be > > overly strict, perhaps preferring Valid paths and giving very low > > preference, but still using, Not Valid paths.” This recommendation > > concerns me because “Not Valid” talks directly to the fact that the > > announcement is, well, not valid – vs just unable to be verified > > (because there’s no BGPsec_Path attribute, for example). The next > > sentence is a reflection of my concern: “Operators should be aware > > that accepting Not Valid announcements…will often be the equivalent of > > treating them as fully Valid.” I-D.sidr-bgpsec-protocol suggests the > > same thing (in 5.1, pointing to this document). I am left with the > > question: why validate at all if the BCP recommendation is to use all > > announcements no matter the state? I obviously realize that it is > > still early days – maybe it is too early for a BCP document if the > > “practice” is not there yet… > > this is the result of a primrose path and, as i am a naggumite, i am > quite willing to be strict here. but how we got here was; paths are > either valid or not; you do not know if it is not valid because of lack > of current rpki data or an attck (much blood spilled here). once you > have swollowed this reduced signaling koolaid, you could have a not > valid path because you just don't have the data, a weaker state than > failure. this left us wussing out on what to do with them in best path > choice. > > how about s/SHOULD NOT/MIGHT NOT/? > > or, as i am a naggumite, i am willing to say just drop the suckers, and > blame it on you :) “naggumite” – it took me a while to figure this out… ;-) My biggest problem with the original text is the normative “SHOULD NOT”, so changing that to “might not” works for me as you’re describing a fact of what may happen in the initial deployments… I am also happy to take the blame for dropping invalid stuff. ;-) … > > M4. Still in Section 7: “To prevent exposure of the internals of BGP > > Confederations [RFC5065], a BGPsec speaker which is a Member-AS of a > > Confederation MUST NOT sign updates sent to another Member-AS of the > > same Confederation.” This is another case where the BGPSec spec says > > something different: Section 4.3. (Processing Instructions for > > Confederation Members) presents a mandatory mechanism that includes > > signing, but not necessarily validating. BTW, if the updates are not > > signed, then the signed path would be broken, even if all the routers > > in the path support BGPSec, right? Is that the recommendation? > > it is common for a bgp confederation to include private ASs for which > there can be no unique authorative router credentials in the rpki. > hence i am suspicious of the protocol spec. As luck would have it, the protocol spec is in IETF Last Call right now. ;-) Short of changing the spec, we can’t have conflicting behavior being specified. … > i do not plan to push the button until you and chairs say we're > converged. Except for the Confederations point above, I think we are. Thanks! Alvaro. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
great review. thanks! > 1. Why is this document a BCP? A BCP is a document that describes > “the community's best current thinking…on what is believed to be the > best way to perform some operations” [rfc2026]. This document meets > that bar of the description, but there is clearly not a lot of > practice behind the considerations – which I think is reflected in the > lack of significant comments from the WG. I would prefer if this > document as Informational, pending some actual experience. But I’ll > settle for a good explanation (to be also included in the Shepherd’s > write-up) of why BCP. because it is, as you quote, the community's best current thinking…on what is believed to be the best way to perform some operations as to significant comments from the wg, welcome to sidr; it's either a poolpah or silent assent. > 2. This document, as a companion of draft-ietf-sidr-bgpsec-protocol, > is the only place where Operational (or Management) Considerations are > discussed. However, important items recommended in RFC5706 > (Guidelines for Considering Operations and Management of New Protocols > and Protocol Extensions), such as migration or fault management are > not covered anywhere. Given the tone and current content of this > document, I don’t think extending it is the way forward -- so, in my > review of draft-ietf-sidr-bgpsec-protocol [1], I asked the authors to > include an Operations and Management Section there and to consider > using this document as the base. Merging this document into > draft-ietf-sidr-bgpsec-protocol is an action that the > WG/authors/Chairs/Shepherds should consider. While that is my > preferred solution, I will move forward with publication of this > document if that is the consensus. sidr has been separating protocol from ops all the way down the line, e.g. in origin validation. heck, you have separated (protocol == sidr) from (ops == sidrops). > M1. In Section 5, you wrote: “As they are not formally verifiable, an > eBGP listener SHOULD NOT strongly trust unsigned security markings > such as communities received across a trust boundary.” After reading > this piece of text several times, I think I picked up on the subtle > message: don’t trust unsigned *security markings* -- vs what I got > from the first n-1 readings: don’t trust communities. I think that > this paragraph would greatly benefit from more details or an example > related to security markings. BGPsec does not sign over communities, so they are not formally trustable. Additionally, outsourcing verification is not prudent security practice. Therefore an eBGP listener SHOULD NOT strongly trust unsigned security signaling, such as communities, received across a trust boundary. > M2. In Section 7. (Routing Policy): “As BGPsec will be rolled out > over…a long time. Hence a normal operator's policy SHOULD NOT be > overly strict, perhaps preferring Valid paths and giving very low > preference, but still using, Not Valid paths.” This recommendation > concerns me because “Not Valid” talks directly to the fact that the > announcement is, well, not valid – vs just unable to be verified > (because there’s no BGPsec_Path attribute, for example). The next > sentence is a reflection of my concern: “Operators should be aware > that accepting Not Valid announcements…will often be the equivalent of > treating them as fully Valid.” I-D.sidr-bgpsec-protocol suggests the > same thing (in 5.1, pointing to this document). I am left with the > question: why validate at all if the BCP recommendation is to use all > announcements no matter the state? I obviously realize that it is > still early days – maybe it is too early for a BCP document if the > “practice” is not there yet… this is the result of a primrose path and, as i am a naggumite, i am quite willing to be strict here. but how we got here was; paths are either valid or not; you do not know if it is not valid because of lack of current rpki data or an attck (much blood spilled here). once you have swollowed this reduced signaling koolaid, you could have a not valid path because you just don't have the data, a weaker state than failure. this left us wussing out on what to do with them in best path choice. how about s/SHOULD NOT/MIGHT NOT/? or, as i am a naggumite, i am willing to say just drop the suckers, and blame it on you :) > M3. Also in Section 7: “…signed paths that are Not Valid and yet > propagated…SHOULD have their signatures kept intact…” Section > 4.2. (Constructing the BGPsec_Path Attribute) of > draft-ietf-sidr-bgpsec-protocol says: “a Signature_Block which is not > deemed 'Valid'…such Signature_Blocks MUST NOT be removed.” The > “SHOULD” in this document is at odds with the “MUST NOT” in the BGPSec > spec; please s/SHOULD/MUST, or (even better) s/SHOULD/should. Because of possible RPKI version skew, an AS Path which does not validate at router R0 might validate at R1. Therefore, signed paths that are Not
Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
Randy: Hi! Do you think we can get an update out for this document soon? I just put the BGPsec spec up for the Jan/5 IESG Telechat, and it would be great if we could get this document in as well. Thanks! Alvaro. On 11/8/16, 12:28 AM, "Randy Bush" mailto:ra...@psg.com>> wrote: thanks for the best review this has had in a while. i am not ignoring you; and may even get a version out for next week. but no promises, as i suspect you folk will think that having a solid ietf network next week is more important :) ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
i think the plan is to shift the -ops document (this one) to the sidrops group...I meant to ask about: "how do we do that?" I'll do that in person tonight. At Wed, 2 Nov 2016 15:35:18 +, "Alvaro Retana (aretana)" wrote: > > Randy: > > Hi! Thanks for working on this document! > > I have two issues I want to highlight upfront, and then some comments > (below). I would like to see these two issues addressed, along with > the Major comments below, before moving the document forward. > > These two upfront issues are probably more questions for the > Chairs/Shepherd. > > 1. Why is this document a BCP? A BCP is a document that describes >“the community's best current thinking…on what is believed to be >the best way to perform some operations” [rfc2026]. This document >meets that bar of the description, but there is clearly not a lot >of practice behind the considerations – which I think is reflected >in the lack of significant comments from the WG. I would prefer if >this document as Informational, pending some actual experience. >But I’ll settle for a good explanation (to be also included in the >Shepherd’s write-up) of why BCP. i think the intent of this document is to write down (document) the inteded 'best practices' for running bgpsec enabled networks. viewed in that light, there aren't any of these things out there today, but as a place to start looking and planning for deployment operations folk (me) want some guidance on what thingsto expect/do/fix as we roll out. i think bcp fits for that... much like bcp 17. I have updated the shepherds doc to reflect the above paragraph's intent/ideas. > 2. This document, as a companion of draft-ietf-sidr-bgpsec-protocol, >is the only place where Operational (or Management) Considerations >are discussed. However, important items recommended in RFC5706 >(Guidelines for Considering Operations and Management of New >Protocols and Protocol Extensions), such as migration or fault >management are not covered anywhere. Given the tone and current Ideally the migration is covered in the protocol document, I see it only talk about as migrations (business events), which seems ok. Migrations of keys or algorithms are covered in other documents and mentioned in this document. which migrations are you referring to? >content of this document, I don’t think extending it is the way >forward -- so, in my review of draft-ietf-sidr-bgpsec-protocol [1], >I asked the authors to include an Operations and Management Section >there and to consider using this document as the base. Merging I'm not sure I'd stick more into the protocol document though, especially things which don't explicitly describe the protocol itself. I think keeping the protocol description/design in one document and the operations of the system in a seperate document isn't unreasonable. I expect the set of ops documents to change/evolve over time, I'd hate to -bis the protocol for operational work later. >this document into draft-ietf-sidr-bgpsec-protocol is an action >that the WG/authors/Chairs/Shepherds should consider. While that >is my preferred solution, I will move forward with publication of >this document if that is the consensus. > > Thanks! > > Alvaro. > > [1] > https://mailarchive.ietf.org/arch/msg/sidr/UOSfI4drrFvnO7271ivU3j9RFm4 > > > Major: > M1. In Section 5, you wrote: “As they are not formally verifiable, an eBGP > listener SHOULD NOT strongly trust unsigned security markings such as > communities received across a trust boundary.” After reading this piece of > text several times, I think I picked up on the subtle message: don’t trust > unsigned *security markings* -- vs what I got from the first n-1 readings: > don’t trust communities. I think that this paragraph would greatly benefit > from more details or an example related to security markings. > > M2. In Section 7. (Routing Policy): “As BGPsec will be rolled out over…a long > time. Hence a normal operator's policy SHOULD NOT be overly strict, perhaps > preferring Valid paths and giving very low preference, but still using, Not > Valid paths.” This recommendation concerns me because “Not Valid” talks > directly to the fact that the announcement is, well, not valid – vs just > unable to be verified (because there’s no BGPsec_Path attribute, for > example). The next sentence is a reflection of my concern: “Operators should > be aware that accepting Not Valid announcements…will often be the equivalent > of treating them as fully Valid.” I-D.sidr-bgpsec-protocol suggests the same > thing (in 5.1, pointing to this document). I am left with the question: why > validate at all if the BCP recommendation is to use all announcements no > matter the state? I obviously realize that it is still early days – maybe it > is too early for a BCP document if the “practice” is not there yet… > > M3. Also in Section 7: “…signed
Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
alvaro, thanks for the best review this has had in a while. i am not ignoring you; and may even get a version out for next week. but no promises, as i suspect you folk will think that having a solid ietf network next week is more important :) randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
