Re: [sidr] draft-ietf-sidr-bgpsec-protocol
Sriram: Hi! Yes, I think I may have read more into Keyur’s comment than what he was asking for, so I think we’re ready to go. ☺ I’ll approve publication. Thanks!! Alvaro. On 1/16/17, 10:10 PM, "Sriram, Kotikalapudi (Fed)" mailto:kotikalapudi.sri...@nist.gov>> wrote: Hi Alvaro, ... snip ... Alvaro wrote: I don’t have an objection for this behavior, but I think we should make the WG (and idr!) aware of the change and get their comments (if any) before I approve the publication. Keyur responded: #Keyur: Ack. Though I was only requesting some text clarification so that it is very clear to the implementers. So there was no change required as Keyur points out. Oliver also agreed with Keyur's observation when I ran this by him last week. Per Keyur's request, I have added the following text clarification in Section 7: During Graceful Restart (GR), restarting and receiving BGPsec speakers MUST follow the procedures specified in [RFC4724] for restarting and receiving BGP speakers, respectively. In particular, the behavior of retaining the forwarding state for the routes in the Loc-RIB [RFC4271] and marking them as stale as well as not differentiating between stale and other information during forwarding will be the same as specified in [RFC4724]. ...snip... Alvaro wrote: …how should an iBGP speaker perform loop detection if there’s no BGPsec_Path attribute? In other words, there is no defined mechanism to run the algorithm in 4.4 without it. I’m not suggesting that you include an empty attribute, but that you indicate in 4.4 that no BGPsec_Path attribute is equivalent to an empty AS_PATH. Per your suggestion, I have added the following text in Section 4.4: Finally, one special case of reconstruction of AS_PATH is when the BGPsec_Path attribute is absent. As explained in Section 4.1, when a BGPsec speaker originates a prefix and sends it to a BGPsec-capable iBGP peer, the BGPsec_Path is not attached. So when received from a BGPsec-capable iBGP peer, no BGPsec_Path attribute in a BGPsec update is equivalent to an empty AS_PATH [RFC4271]. Please let me know if you have any comments/questions. Thank you. Sriram ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol
Hi Alvaro, ... snip ... Alvaro wrote: >>I don’t have an objection for this behavior, but I think >>we should make the WG (and idr!) aware of the change >>and get their comments (if any) before I approve the publication. Keyur responded: >#Keyur: Ack. Though I was only requesting some text clarification >so that it is very clear to the implementers. So there was no change required as Keyur points out. Oliver also agreed with Keyur's observation when I ran this by him last week. Per Keyur's request, I have added the following text clarification in Section 7: During Graceful Restart (GR), restarting and receiving BGPsec speakers MUST follow the procedures specified in [RFC4724] for restarting and receiving BGP speakers, respectively. In particular, the behavior of retaining the forwarding state for the routes in the Loc-RIB [RFC4271] and marking them as stale as well as not differentiating between stale and other information during forwarding will be the same as specified in [RFC4724]. ...snip... Alvaro wrote: >>…how should an iBGP speaker perform loop detection >>if there’s no BGPsec_Path attribute? In other words, >>there is no defined mechanism to run the algorithm in 4.4 without it. >> >>I’m not suggesting that you include an empty attribute, >>but that you indicate in 4.4 that no BGPsec_Path attribute >>is equivalent to an empty AS_PATH. Per your suggestion, I have added the following text in Section 4.4: Finally, one special case of reconstruction of AS_PATH is when the BGPsec_Path attribute is absent. As explained in Section 4.1, when a BGPsec speaker originates a prefix and sends it to a BGPsec-capable iBGP peer, the BGPsec_Path is not attached. So when received from a BGPsec-capable iBGP peer, no BGPsec_Path attribute in a BGPsec update is equivalent to an empty AS_PATH [RFC4271]. Please let me know if you have any comments/questions. Thank you. Sriram ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol
Hi Alvaro, Comments inlined #Keyur From: "Alvaro Retana (aretana)" Date: Friday, January 6, 2017 at 3:10 PM To: "Sriram, Kotikalapudi (Fed)" , Keyur Patel Cc: "sidr-cha...@ietf.org" , sidr , "mlepin...@ncf.edu" Subject: Re: draft-ietf-sidr-bgpsec-protocol On 1/6/17, 12:40 AM, "Sriram, Kotikalapudi (Fed)" wrote: [Cut the distribution list a little.] Sriram: Hi! Happy New Year! I have some comments on this, please see below. Thanks! Alvaro. … | | 1) Section 4.1 “The BGPsec Path attribute and the AS_PATH attribute are mutually | | exclusive. That is, any update message containing the BGPsec Path attribute MUST NOT | | contain the AS_PATH attribute”. For any restarting speakers in a GR mode, where the bgp | | capability is not exchanged, the existing stale routes won’t have an AS_PATH attribute. We | | could add some clarifying that helps to indicate that such routes should be considered | | valid in stale mode (till they get refreshed)? | | [Sriram] As you have clarified for me on the phone, what you are saying here is that the | two BGPsec peers lost the BGPsec session and now restarting in GR mode, but they have not | exchanged BGPsec capability this time. Hence, they are now simple BGP (non-BGPsec) peers | in GR mode. RFC4271 considers update message received without a well-known AS_PATH | attribute as an error, and unfortunately in this case the cached BGPsec updates do not have | AS_PATH (albeit they have BGPsec_Path). So you are saying "the router should not panic" | and instead simply treat each cached update as NOT-IN-ERROR even though it is missing | AS_PATH attribute. This way the GR can work properly. Of course, shortly the updates will | have AS_PATH (and not considered in error) when they get refreshed (over the new simple | BGP session). Per your suggestion, I will include new text in Section 7 to describe this | required behavior for the GR mode. I don’t have an objection for this behavior, but I think we should make the WG (and idr!) aware of the change and get their comments (if any) before I approve the publication. #Keyur: Ack. Though I was only requesting some text clarification so that it is very clear to the implementers. Regards, Keyur … | | 3) Section 5 and Section 5.2, 1st paragraph: RFC4271 considers update message received | | without a well-known AS_PATH attribute as an error. We need some text to clarify the | | (error handling if any) behavior when an update message is received without a bgpsec and | | an aspath attribute. The current draft text seems unclear about generation of bgpsec | | attribute as well (in a ibgp scenario). Is it a requirement to generate an empty bgpsec | | attribute? | | [Sriram] As you have clarified for me over the phone, RFC 4271 (page 26) says the | following : | | "When a BGP speaker originates a route then: | b) the originating speaker includes an empty AS_PATH attribute in |all UPDATE messages sent to internal peers. (An empty AS_PATH | attribute is one whose length field contains the value zero)." | | | [Sriram] So what needs to be said in the BGPsec document is the following: The | BGPsec_Path attribute is not attached in updates originated inside an AS and propagated to | BGPsec capable internal peers. However, when a route is originated inside an AS and | propagated to non-BGPsec internal peers, an empty AS_PATH attribute is included in the | update (see [RFC 4271], page 26). The Route Selection Section (9.1.2) in RFC4271 is not explicit about performing loop detection only on eBGP sessions – the criteria is generic to any route, so there is a possibility that a BGPsec-capable router may want to perform loop detection on an iBGP-received Update. Given this text from Section 5 in the BGPsec spec: Whenever the use of AS path information is called for (e.g., loop detection, or use of AS path length in best path selection) the externally visible behavior of the implementation shall be the same as if the implementation had run the algorithm in Section 4.4 and used the resulting AS_PATH attribute as it would for a non-BGPsec update message. …how should an iBGP speaker perform loop detection if there’s no BGPsec_Path attribute? In other words, there is no defined mechanism to run the algorithm in 4.4 without it. I’m not suggesting that you include an empty attribute, but that you indicate in 4.4 that no BGPsec_Path attribute is equivalent to an empty AS_PATH. Thanks! Alvaro. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol
re keyur's point 4. the issue is that 4271 has semantics of AS_PATH, bgpsec replaces it with BGPSEC_PATH, but bgpsec does not explicitly repeat things such as loop detection using BGPSEC_PATH. instead of this becoming another text explosion, a simple statement that, in bgpsec, the following AS_PATH semantics of 4271: , hold analogously for BGPSEC_PATH. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol
On 1/6/17, 12:40 AM, "Sriram, Kotikalapudi (Fed)" wrote: [Cut the distribution list a little.] Sriram: Hi! Happy New Year! I have some comments on this, please see below. Thanks! Alvaro. … | | 1) Section 4.1 “The BGPsec Path attribute and the AS_PATH attribute are mutually | | exclusive. That is, any update message containing the BGPsec Path attribute MUST NOT | | contain the AS_PATH attribute”. For any restarting speakers in a GR mode, where the bgp | | capability is not exchanged, the existing stale routes won’t have an AS_PATH attribute. We | | could add some clarifying that helps to indicate that such routes should be considered | | valid in stale mode (till they get refreshed)? | | [Sriram] As you have clarified for me on the phone, what you are saying here is that the | two BGPsec peers lost the BGPsec session and now restarting in GR mode, but they have not | exchanged BGPsec capability this time. Hence, they are now simple BGP (non-BGPsec) peers | in GR mode. RFC4271 considers update message received without a well-known AS_PATH | attribute as an error, and unfortunately in this case the cached BGPsec updates do not have | AS_PATH (albeit they have BGPsec_Path). So you are saying "the router should not panic" | and instead simply treat each cached update as NOT-IN-ERROR even though it is missing | AS_PATH attribute. This way the GR can work properly. Of course, shortly the updates will | have AS_PATH (and not considered in error) when they get refreshed (over the new simple | BGP session). Per your suggestion, I will include new text in Section 7 to describe this | required behavior for the GR mode. I don’t have an objection for this behavior, but I think we should make the WG (and idr!) aware of the change and get their comments (if any) before I approve the publication. … | | 3) Section 5 and Section 5.2, 1st paragraph: RFC4271 considers update message received | | without a well-known AS_PATH attribute as an error. We need some text to clarify the | | (error handling if any) behavior when an update message is received without a bgpsec and | | an aspath attribute. The current draft text seems unclear about generation of bgpsec | | attribute as well (in a ibgp scenario). Is it a requirement to generate an empty bgpsec | | attribute? | | [Sriram] As you have clarified for me over the phone, RFC 4271 (page 26) says the | following : | | "When a BGP speaker originates a route then: | b) the originating speaker includes an empty AS_PATH attribute in |all UPDATE messages sent to internal peers. (An empty AS_PATH | attribute is one whose length field contains the value zero)." | | | [Sriram] So what needs to be said in the BGPsec document is the following: The | BGPsec_Path attribute is not attached in updates originated inside an AS and propagated to | BGPsec capable internal peers. However, when a route is originated inside an AS and | propagated to non-BGPsec internal peers, an empty AS_PATH attribute is included in the | update (see [RFC 4271], page 26). The Route Selection Section (9.1.2) in RFC4271 is not explicit about performing loop detection only on eBGP sessions – the criteria is generic to any route, so there is a possibility that a BGPsec-capable router may want to perform loop detection on an iBGP-received Update. Given this text from Section 5 in the BGPsec spec: Whenever the use of AS path information is called for (e.g., loop detection, or use of AS path length in best path selection) the externally visible behavior of the implementation shall be the same as if the implementation had run the algorithm in Section 4.4 and used the resulting AS_PATH attribute as it would for a non-BGPsec update message. …how should an iBGP speaker perform loop detection if there’s no BGPsec_Path attribute? In other words, there is no defined mechanism to run the algorithm in 4.4 without it. I’m not suggesting that you include an empty attribute, but that you indicate in 4.4 that no BGPsec_Path attribute is equivalent to an empty AS_PATH. Thanks! Alvaro. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol
My previous post of this message seems to have line wrap issue. Resending ... hopefully this avoids that issue. - Sriram --- Keyur, Thank you for taking the time to read and offer comments. I find the comments very insightful and helpful. My comments are marked with [Sriram] below. >From: Keyur Patel ke...@arrcus.com >Sent: Wednesday, January 4, 2017 5:53 PM >The document is well written, easy to read and follow. >Some minor comments are listed below: >1) Section 4.1 “The BGPsec Path attribute and the AS_PATH attribute are >mutually exclusive. That is, any update message containing the BGPsec Path >attribute MUST NOT contain the AS_PATH attribute”. For any restarting >speakers in a GR mode, where the bgp capability is not exchanged, the existing >stale routes won’t have an AS_PATH attribute. We could add some clarifying >that helps to indicate that such routes should be considered valid in stale >mode (till they get refreshed)? [Sriram] As you have clarified for me on the phone, what you are saying here is that the two BGPsec peers lost the BGPsec session and now restarting in GR mode, but they have not exchanged BGPsec capability this time. Hence, they are now simple BGP (non-BGPsec) peers in GR mode. RFC4271 considers update message received without a well-known AS_PATH attribute as an error, and unfortunately in this case the cached BGPsec updates do not have AS_PATH (albeit they have BGPsec_Path). So you are saying "the router should not panic" and instead simply treat each cached update as NOT-IN-ERROR even though it is missing AS_PATH attribute. This way the GR can work properly. Of course, shortly the updates will have AS_PATH (and not considered in error) when they get refreshed (over the new simple BGP session). Per your suggestion, I will include new text in Section 7 to describe this required behavior for the GR mode. >2) 4.1 4th paragraph: "Note also that new signatures are only added to a >BGPsec update message when a BGPsec speaker is generating an update message to >send to an external peer (i.e., when the AS number of the peer is not equal to >the BGPsec speaker's own AS number). Therefore, a BGPsec speaker who only >sends BGPsec update messages to peers within its own AS does not need to >possess any private signature keys." This text doesn't seem to apply to confed >peers? If so, it would be nice to clarify that this text doesn't apply to any >confed peers. [Sriram] You have clarified in our phone conversation that you consider the inter-AS-member sessions as "iBGP" since they are all within a confederation AS domain. The BGPsec document considers the inter-AS-member sessions as "eBGP" (not "iBGP") and intra-Member-AS sessions as "iBGP". You also clarified that you may call inter-AS-member sessions as "confederation-eBGP" sessions. Obviously, private key is required to sign over such "confederation-eBGP/BGPsec" sessions. I understand your point. I will put in new text (notes) to clarify this in the document. >3) Section 5 and Section 5.2, 1st paragraph: RFC4271 considers update message >received without a well-known AS_PATH attribute as an error. We need some >text to clarify the (error handling if any) behavior when an update message is >received without a bgpsec and an aspath attribute. The current draft text >seems unclear about generation of bgpsec attribute as well (in a ibgp >scenario). Is it a requirement to generate an empty bgpsec attribute? [Sriram] As you have clarified for me over the phone, RFC 4271 (page 26) says the following : "When a BGP speaker originates a route then: b) the originating speaker includes an empty AS_PATH attribute in all UPDATE messages sent to internal peers. (An empty AS_PATH attribute is one whose length field contains the value zero)." [Sriram] So what needs to be said in the BGPsec document is the following: The BGPsec_Path attribute is not attached in updates originated inside an AS and propagated to BGPsec capable internal peers. However, when a route is originated inside an AS and propagated to non-BGPsec internal peers, an empty AS_PATH attribute is included in the update (see [RFC 4271], page 26). >4) With an AS_PATH attribute in 4271 there was loop detection in place. >With BGPSec I don’t see that being called explicitly other than a passing >remark in section 5. Section 5.2 should have a check that allows a BGPsec >speaker to bail out of a validation procedure when a aspath loop is detected. [Sriram] I agree. I will include loop detection in the list of error checks in Section 5.2. Sriram ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol
Keyur, Thank you for taking the time to read and offer comments. I find the comments very insightful and helpful. My comments are marked with [Sriram] below. >From: Keyur Patel ke...@arrcus.com >Sent: Wednesday, January 4, 2017 5:53 PM >The document is well written, easy to read and follow. >Some minor comments are listed below: >1) Section 4.1 “The BGPsec Path attribute and the AS_PATH attribute are >mutually exclusive. That is, any update message containing the BGPsec Path >attribute MUST NOT contain the AS_PATH attribute”. For any restarting >speakers in a GR mode, where the bgp capability is not exchanged, the existing >stale routes won’t have an AS_PATH attribute. We could add some clarifying >that helps to indicate that such routes should be considered valid in stale >mode (till they get refreshed)? [Sriram] As you have clarified for me on the phone, what you are saying here is that the two BGPsec peers lost the BGPsec session and now restarting in GR mode, but they have not exchanged BGPsec capability this time. Hence, they are now simple BGP (non-BGPsec) peers in GR mode. RFC4271 considers update message received without a well-known AS_PATH attribute as an error, and unfortunately in this case the cached BGPsec updates do not have AS_PATH (albeit they have BGPsec_Path). So you are saying "the router should not panic" and instead simply treat each cached update as NOT-IN-ERROR even though it is missing AS_PATH attribute. This way the GR can work properly. Of course, shortly the updates will have AS_PATH (and not considered in error) when they get refreshed (over the new simple BGP session). Per your suggestion, I will include new text in Section 7 to describe this required behavior for the GR mode. >2) 4.1 4th paragraph: "Note also that new signatures are only added to a >BGPsec update message when a BGPsec speaker is generating an update message to >send to an external peer (i.e., when the AS number of the peer is not equal to >the BGPsec speaker's own AS number). Therefore, a BGPsec speaker who only >sends BGPsec update messages to peers within its own AS does not need to >possess any private signature keys." This text doesn't seem to apply to confed >peers? If so, it would be nice to clarify that this text doesn't apply to any >confed peers. [Sriram] You have clarified in our phone conversation that you consider the inter-AS-member sessions as "iBGP" since they are all within a confederation AS domain. The BGPsec document considers the inter-AS-member sessions as "eBGP" (not "iBGP") and intra-Member-AS sessions as "iBGP". You also clarified that you may call inter-AS-member sessions as "confederation-eBGP" sessions. Obviously, private key is required to sign over such "confederation-eBGP/BGPsec" sessions. I understand your point. I will put in new text (notes) to clarify this in the document. >3) Section 5 and Section 5.2, 1st paragraph: RFC4271 considers update message >received without a well-known AS_PATH attribute as an error. We need some >text to clarify the (error handling if any) behavior when an update message is >received without a bgpsec and an aspath attribute. The current draft text >seems unclear about generation of bgpsec attribute as well (in a ibgp >scenario). Is it a requirement to generate an empty bgpsec attribute? [Sriram] As you have clarified for me over the phone, RFC 4271 (page 26) says the following : "When a BGP speaker originates a route then: b) the originating speaker includes an empty AS_PATH attribute in all UPDATE messages sent to internal peers. (An empty AS_PATH attribute is one whose length field contains the value zero)." [Sriram] So what needs to be said in the BGPsec document is the following: The BGPsec_Path attribute is not attached in updates originated inside an AS and propagated to BGPsec capable internal peers. However, when a route is originated inside an AS and propagated to non-BGPsec internal peers, an empty AS_PATH attribute is included in the update (see [RFC 4271], page 26). >4) With an AS_PATH attribute in 4271 there was loop detection in place. >With BGPSec I don’t see that being called explicitly other than a passing >remark in section 5. Section 5.2 should have a check that allows a BGPsec >speaker to bail out of a validation procedure when a aspath loop is detected. [Sriram] I agree. I will include loop detection in the list of error checks in Section 5.2. Sriram ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol
did i miss the response to this? i think some of the points are important. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol
[adding routing-ads] From: Keyur Patel Date: Wednesday, January 4, 2017 at 2:17 PM To: Jonathan Hardwick , "Alvaro Retana (aretana)" , Zhangxian Xian , Jon Hudson Cc: rtg-dir , "sidr-cha...@ietf.org" , sidr , "Sriram, Kotikalapudi (Fed)" , "mlepin...@ncf.edu" Subject: draft-ietf-sidr-bgpsec-protocol Hello, Apologies for the delayed response. I have been selected as the Routing Directorate QA reviewer for draft-ietf-sidr-bgpsec-protocol. The Routing Directorate QA reviews are intended to be a support to improve the quality of RTG Area documents as they pass through the IETF process. This is the QA review at the time of the WG document adoption poll. Summary: This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems (ASes) through which a BGP update message passes. The document is well written, easy to read and follow. Some minor comments are listed below: Comments for the authors: 1) Section 4.1 “The BGPsec Path attribute and the AS_PATH attribute are mutually exclusive. That is, any update message containing the BGPsec Path attribute MUST NOT contain the AS_PATH attribute”. For any restarting speakers in a GR mode, where the bgp capability is not exchanged, the existing stale routes won’t have an AS_PATH attribute. We could add some clarifying that helps to indicate that such routes should be considered valid in stale mode (till they get refreshed)? 2) 4.1 4th paragraph: “Note also that new signatures are only added to a BGPsec update message when a BGPsec speaker is generating an update message to send to an external peer (i.e., when the AS number of the peer is not equal to the BGPsec speaker's own AS number). Therefore, a BGPsec speaker who only sends BGPsec update messages to peers within its own AS does not need to possess any private signature keys.” This text doesn’t seem to apply to confed peers? If so, it would be nice to clarify that this text doesn’t apply to any confed peers. 3) Section 5 and Section 5.2, 1st paragraph: RFC4271 considers update message received without a wellknown AS_PATH attribute as an error. We need some text to clarify the (error handling if any) behavior when an update message is received without a bgpsec and an aspath attribute. The current draft text seems unclear about generation of bgpsec attribute as well (in a ibgp scenario). Is it a requirement to generate an empty bgpsec attribute? 4) With an AS_PATH attribute in 4271 there was loop detection in place. With BGPSec I don’t see that being called explicitly other than a passing remark in section 5. Section 5.2 should have a check that allows a BGPsec speaker to bail out of a validation procedure when a aspath loop is detected. Best Regards, Keyur ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
This conversation seems to have come to a close. The wg chairs see wg consensus as follows: The problem is real enough to merit a protocol change. The change is to cover more raw info in the signatures, rather than signature chaining only, along the lines of http://www.ietf.org/mail-archive/web/sidr/current/msg07258.html (see also the new archiving tool https://mailarchive.ietf.org/arch/msg/sidr/sXUj7lgieri0Wrv5PK5u7PfLtxc). In addition, maintaining ordering was also noted as important to some http://www.ietf.org/mail-archive/web/sidr/current/msg07261.html http://www.ietf.org/mail-archive/web/sidr/current/msg07270.html http://www.ietf.org/mail-archive/web/sidr/current/msg07271.html The authors of draft-ietf-sidr-bgpsec-protocol-13 are requested to submit a revised version of the draft. The changes are significant enough that the revised draft will go through a wglc, focussed on the changes for this issue, so shorter than normal. —Sandy, speaking as one of the wg co-chairs signature.asc Description: Message signed with OpenPGP using GPGMail ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
> In the example with -- > A --> B --> C --> D -->, if B and C (the ones > that were signing but not verifying) return to the update to verify, > then they will realize that the update they last signed (for the > prefix) was invalid, and will propagate an alternate valid signed > announcement or send a withdrawal message to D. and all the packts will return to their origins with a loud swoosh and re-route correctly :) > At this point, B and C have taken their corrective action. not really. the internet is all about the data plane. the control plane is there to help the data plane. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
>> 3. In consideration of the above (#2), the document should instead >> strongly recommend that “if an AS signs an update without verifying >> first, >> it SHOULD return to the update at its earliest and verify, and >> forward >> a new signed update, if necessary." Make this a strong BCP >> recommendation. > >Without replay protection, I don't see how this recommendation would >help. I.e., the old signed update would still be valid. > In the example with -- > A --> B --> C --> D -->, if B and C (the ones that were signing but not verifying) return to the update to verify, then they will realize that the update they last signed (for the prefix) was invalid, and will propagate an alternate valid signed announcement or send a withdrawal message to D. At this point, B and C have taken their corrective action. Their well-behaving neighbors (others besides D) will act on the new valid announcement or the withdrawal. But if D is still malicious and suppresses the new valid announcement or the withdraw, then that would be a classic withdraw suppression / replay attack. (B and C are not contributing to collusion anymore at this point.) And the solution at that point is whatever remedy draft-ietf-sidr-bgpsec-rollover-04 offers. Sriram ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
On 2015-09-10 15:09, Stephen Kent wrote: At least initially, sig order was required to match the AS transit order, to ensure that the AS transit order is accurately represented. Is that no longer true? Are you talking about (1) the order of the signatures on the wire, (2) the order of which AS path is covered by which signature, or (3) the chronological order in which the signatures are generated? I think Rob and I were talking about (3), but Rob should tell me if I misunderstood him. For (1), the order needs to specified such that each signature can be correctly verified. Having the order of the signatures match the AS transit order seems like the most sensible way to do this. For (2), I think it's critical that each signature covers that correct AS path, in the correct order. For (3), the signatures will typically be generated in order, but I don't see the value of enforcing that. I.e., while I don't see the point of pre-computing signatures before including them in a BGPsec UPDATE, I also don't see any harm in it. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
David, ... What does the guarantee about signature order provide? I don't see how it's useful, but I could be missing something. At least initially, sig order was required to match the AS transit order, to ensure that the AS transit order is accurately represented. Is that no longer true? Steve ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
At Tue, 08 Sep 2015 21:21:52 -0400, David Mandelberg wrote: > > What does the guarantee about signature order provide? I don't see how > it's useful, but I could be missing something. I can't point to any concrete threat. Just a suspicion that we should grab a cheap opportunity to reduce the number of potential violations of the Principal of Least Astonishment. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
On 2015-09-08 21:07, Rob Austein wrote: Hmm, I would have thought we'd want to keep the chaining, in the sense that non-originating would sign the previous signature. I've no real objection to signing everything else again, it's just removal of the previous signature that I find odd here. The benefit I see to keeping the signature chaining is that it adds an ordering constraint to the signatures (signature A must have been created after signature B), corresponding to the order in which we expect the update to travel between signers. This seems like a good thing, and I don't see why we'd want to remove it. As you've demonstrated, it doesn't remove all possible forms of mischief, but it raises the bar a bit, and it's cheap, so why not? I agree that signature chaining provides the guarantee you stated, that signatures were generated in order. But in the presence of non-validating signers, I don't think it provides any other guarantee. What does the guarantee about signature order provide? I don't see how it's useful, but I could be missing something. Am I missing something? Where's the benefit in removing the chaining? There's no benefit to removing it, except that I don't see any benefit to keeping it (if we sign the full data, as I described). -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
Hmm, I would have thought we'd want to keep the chaining, in the sense that non-originating would sign the previous signature. I've no real objection to signing everything else again, it's just removal of the previous signature that I find odd here. The benefit I see to keeping the signature chaining is that it adds an ordering constraint to the signatures (signature A must have been created after signature B), corresponding to the order in which we expect the update to travel between signers. This seems like a good thing, and I don't see why we'd want to remove it. As you've demonstrated, it doesn't remove all possible forms of mischief, but it raises the bar a bit, and it's cheap, so why not? Am I missing something? Where's the benefit in removing the chaining? ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
On 2015-08-27 15:23, Borchert, Oliver wrote: If I understand Davids attack vector correct than the attack would look as follows: For the path -> A -> B -> C -> D -> E with A and D conspiring and B and C only signing but not validating: A signs the path to D and not to B but sends it to B. Because B and C do not validate, just sign they forward the path to D. D removed B and C from the path and forwards the path as -> A -> D to E. Now E verifies the path as valid and moves on. If this is what David had in mind then I agree that the security guarantee in 7.1 does not hold up. This is one type of attack that uses the issue I raised, but this specific attack doesn't seem problematic to me. A and D can always set up a BGPsec tunnel to accomplish the same result of removing B and C from the path, and there's not much we can do to stop that. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
On 2015-09-04 13:08, Sriram, Kotikalapudi wrote: 3. In consideration of the above (#2), the document should instead strongly recommend that “if an AS signs an update without verifying first, it SHOULD return to the update at its earliest and verify, and forward a new signed update, if necessary." Make this a strong BCP recommendation. Without replay protection, I don't see how this recommendation would help. I.e., the old signed update would still be valid. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
On 2015-08-26 22:49, Rob Austein wrote: At Wed, 26 Aug 2015 17:26:24 -0400, David Mandelberg wrote: ... I think this problem might be fixed if we modify the protocol to sign all of the preceding signed data (rather than just the immediate, previous signature). Agreed, assuming this means adding the (theoretically invariant) fields from the data to be signed in section 4.1 to the data to be signed in section 4.2. Taking "Origin AS Number" in section 4.1 as equivalent to "Signer's AS Number" in section 4.2, this leaves the algorithm suite identifier, the AFI, the SAFI, and the NLRI to be added to the data to be signed in section 4.2. I doubt that there's any practical attack based on fiddling with the algorithm suite identifier (I'd expect any games there to cause validation failure, end of story), but maybe somebody has a more twisted imagination than mine, and, given that the algorithm suite ID is one byte long, I don't think it's worth trying to optimize that byte out of the section 4.2 signature. Presumably we want to keep the existing signature chaining, so I wouldn't remove anything from the data to be signed in section 4.2, just add the fields that are currently only present in section 4.1. David, if this is consistent with what you meant, cool, if not, say on. It is not consistent with what I meant, so I'll be more explicit about what I meant. I meant to remove the signature chaining, and have each AS sign the data that is currently covered by signature chaining. I.e., each AS (origin or intermediary) would sign the same data structure (with different, but related, data in the structure): Target AS Number (4 octets) AS Count (4 octets) instances of: AS Number (4 octets) instances of: pCount (1 octet) Flags (1 octet) Algorithm Suite Id. (1 octet) AFI (2 octets) SAFI (1 octet) NLRI (variable) The sequence of AS Numbers is split from the sequence of (pCount, Flags) to preserve alignment, but the two sequences form a single logical sequence of (AS Number, pCount, Flags). (This could also be represented with 2 bytes of padding per AS, without 4-byte alignment, or with 3 parallel sequences; I don't really care which.) Regardless of the logical sequence's representation, the first (AS Number, pCount, Flags) entry corresponds to (Origin AS Number, pCount, Flags) from section 4.1. Subsequent entries correspond to (Signer's AS Number, pCount, Flags) from section 4.2, in order from the origin's next hop to the current signer. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
Doug and I have discussed the issues raised in this thread in some detail. We feel that the following considerations (with corresponding changes in the document) would help resolve the issue(s) we are dealing with: 1. As mentioned already, signature should cover more data so that the collusion vulnerability that David pointed out can be addressed. 2. It was a conscious design decision to not require (MUST) validation before path selection and signing in all cases. Lazy (or deferred) evaluation (e.g., the ability to select and sign a path before validation) adds performance / robustness options to implementations that address real operational concerns (e.g., convergence time on table dumps, bootstrap, etc.) that were identified early in the BGPsec design process. 3. In consideration of the above (#2), the document should instead strongly recommend that “if an AS signs an update without verifying first, it SHOULD return to the update at its earliest and verify, and forward a new signed update, if necessary." Make this a strong BCP recommendation. 4. If this recommendation (#3) is followed, then other collusion/replay effects that have been identified on the list will be short lived (e.g. Oliver’s: http://www.ietf.org/mail-archive/web/sidr/current/msg07248.html ). Adverse effects would be short lived, if the duration of deferment of verification (if any) is short. Sriram ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
Speaking as a regular ol’ member On Aug 27, 2015, at 5:02 PM, Randy Bush wrote: >>> an intermediate AS, which does not validate but signs, could apply >> I’d say that the intermediate AS who didn’t verify the signatures it >> received could be acting on bad info at any time, without any >> conspiring ASs around. The intermediate AS has no more assurance than >> a non-bgpsec speaker that the route it receives is valid. > > it is not worse than unsecured is a form of reasoning i do not buy. > > >> But the intermediate AS and any bgp4 (i.e. non-bgpsec speakers?) peers >> have chosen to be insecure - I see no reason to be concerned. > > same fallacious argument. we are supposed to be making things better, > not leaving them the same. Are you saying that any system that does NOT check the protections and does not spot invalid signatures should still be protected? I think that’s a pretty tall order. My concern is with those who do check the signature but who, because conspiring ASs “violate the guarantee”, do not get the bgpsec protection in some way. David’s suggestion that more of the data should be covered by the signature still does not help the hapless intermediate AS who does not check the signature, I would think. That AS could still fooled. So I don’t think that the new signature makes anything better for the non-checkers. —Sandy, speaking as a regular ol’ member signature.asc Description: Message signed with OpenPGP using GPGMail ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
> >If I understand your scenario correctly, as far as folks further along >the path are concerned, this is a replay attack by D. That D is doing >this to cover up something bad that A is doing to B and C is almost >irrelevant, as is the specific nature of whatever bad thing A is doing >to B and C. > >So, yeah, OK, it's a form of collusion, but it's not one that relies >on a weakness in the signature semantics, it's one that relies on lack >of protection against replay attacks, something the WG discussed and >rejected. Can't speak for anybody else, but I'm not particularly >interested in exhuming the replay horse at this late date. > It appears you agree that the two-update collusion scenario that I described is feasible. It is basically another mechanism by which the colluders seem to achieve the same effect as in David's collusion scenario. (I think so, but I'm open to being proven wrong about that.) The latter, it appears, can be mitigated by signing 'all of the preceding signed data', but not the former (two-update collusion). Both scenarios or threats rely on intermediate ASes not verifying. So both of these scenarios are mitigated by requiring intermediate ASes to verify. This is the observation I would like to make. Since you made contrary comments, let me point out respectfully that replay attack mitigation is in the requirements (RFC 7353): 4.3 Replay of BGP UPDATE messages need not be completely prevented, but a BGPsec design SHOULD provide a mechanism to control the window of exposure to replay attacks. And there is an active SIDR WG draft dealing with replay attack mitigation: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-04#section-4.2 However, a solution for the specific collusion threat we are discussing does not benefit at all from replay attack mitigation techniques. All that D is doing (in my example) is to hold the first update for 15 or 30 seconds. The bgpsec-rollover draft proposes router key rollovers, but (thank goodness) not on that small/tiny (seconds) time scale! Sriram ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
>> an intermediate AS, which does not validate but signs, could apply > I’d say that the intermediate AS who didn’t verify the signatures it > received could be acting on bad info at any time, without any > conspiring ASs around. The intermediate AS has no more assurance than > a non-bgpsec speaker that the route it receives is valid. it is not worse than unsecured is a form of reasoning i do not buy. >> prefix-based local policy based on the wrong prefix. same for any >> bgp4 peers it may have. > > I see nothing in David’s message about a prefix, so I’m not sure what > you are talking about. sorry, i forgot that bgp announces beers. the colluding systems could have signed a hash of lager when the label on the announcement was pils. the intermediate system which does not validate could base it's mains order on pils and tell it's non-validating peers to have a pils with them. > But the intermediate AS and any bgp4 (i.e. non-bgpsec speakers?) peers > have chosen to be insecure - I see no reason to be concerned. same fallacious argument. we are supposed to be making things better, not leaving them the same. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
Speaking as regular ol’ member: On Aug 26, 2015, at 8:20 PM, Randy Bush wrote: > good catch. > > one consequence > > an intermediate AS, which does not validate but signs, could apply I’d say that the intermediate AS who didn’t verify the signatures it received could be acting on bad info at any time, without any conspiring ASs around. The intermediate AS has no more assurance than a non-bgpsec speaker that the route it receives is valid. So I don’t think anything that happens to the intermediate AS is something to worry about. > prefix-based local policy based on the wrong prefix. same for any > bgp4 peers it may have. I see nothing in David’s message about a prefix, so I’m not sure what you are talking about. But the intermediate AS and any bgp4 (i.e. non-bgpsec speakers?) peers have chosen to be insecure - I see no reason to be concerned. —Sandy, speaking as regular ol’ member signature.asc Description: Message signed with OpenPGP using GPGMail ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
I noticed Outlook changed some characters so here again: If I understand Davids attack vector correct than the attack would look as follows: For the path -> A -> B -> C -> D -> E with A and D conspiring and B and C only signing but not validating: A signs the path to D and not to B but sends it to B. Because B and C do not validate, just sign they forward the path to D. D removed B and C from the path and forwards the path as -> A -> D to E. Now E verifies the path as valid and moves on. If this is what David had in mind then I agree that the security guarantee in 7.1 does not hold up. Oliver On 8/27/15, 3:15 PM, "sidr on behalf of Borchert, Oliver" wrote: >If I understand David¹s attack vector correct than the attack would look >as follows: > >For the path ‹ > A ‹> B ‹> C ‹> D ‹> E with A and D conspiring and B and C >only signing but not validating: > >A signs the path to D and not to B but sends it to B. Because B and C >don¹t validate, just sign they forward the path to D. >D removed B and C from the path and forwards the path as ‹> A ‹> D to E. >Now E verifies the path as valid and moves on. > >If this is what David had in mind then I agree that the security guarantee >in 7.1 does not hold up. > > >Oliver > > > >On 8/27/15, 1:58 PM, "sidr on behalf of Rob Austein" > wrote: > >>At Thu, 27 Aug 2015 15:45:49 +, Sriram, Kotikalapudi wrote: >>> >>> What do you think of the following two-update collusion scenario? >>> -- > A --> B --> C --> D --> E >>> A and D are colluding. B and C are signing without verifying. >>> First update at time= t0: >>> A signs and forwards an update normally (without any corruption). >>> The update propagates via B and C to D. >>> D receives it and stores it, but does not forward to E (or anyone). >>> Second update at time= t1 (= t0 + delta): >>> A sends an intentionally corrupted version of the update (signed), >>> while keeping the same NLRI as before. >>> B and C are still signing but not verifying. >>> The update propagates via B and C to D. Now D replaces >>> this corrupted update with the earlier clean one (received at t0), >>> and propagates to E. The resulting update from D to E is valid. >>> One can argue that there is violation of the guarantee (in Section 7.1) >>> at time t1. The valid route propagated from D to E does not >>> agree with the route that B or C forwarded (at time t1) >>> for the NLRI in consideration. >> >>If I understand your scenario correctly, as far as folks further along >>the path are concerned, this is a replay attack by D. That D is doing >>this to cover up something bad that A is doing to B and C is almost >>irrelevant, as is the specific nature of whatever bad thing A is doing >>to B and C. >> >>So, yeah, OK, it's a form of collusion, but it's not one that relies >>on a weakness in the signature semantics, it's one that relies on lack >>of protection against replay attacks, something the WG discussed and >>rejected. Can't speak for anybody else, but I'm not particularly >>interested in exhuming the replay horse at this late date. >> >>___ >>sidr mailing list >>sidr@ietf.org >>https://www.ietf.org/mailman/listinfo/sidr > >___ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
If I understand David¹s attack vector correct than the attack would look as follows: For the path ‹ > A ‹> B ‹> C ‹> D ‹> E with A and D conspiring and B and C only signing but not validating: A signs the path to D and not to B but sends it to B. Because B and C don¹t validate, just sign they forward the path to D. D removed B and C from the path and forwards the path as ‹> A ‹> D to E. Now E verifies the path as valid and moves on. If this is what David had in mind then I agree that the security guarantee in 7.1 does not hold up. Oliver On 8/27/15, 1:58 PM, "sidr on behalf of Rob Austein" wrote: >At Thu, 27 Aug 2015 15:45:49 +, Sriram, Kotikalapudi wrote: >> >> What do you think of the following two-update collusion scenario? >> -- > A --> B --> C --> D --> E >> A and D are colluding. B and C are signing without verifying. >> First update at time= t0: >> A signs and forwards an update normally (without any corruption). >> The update propagates via B and C to D. >> D receives it and stores it, but does not forward to E (or anyone). >> Second update at time= t1 (= t0 + delta): >> A sends an intentionally corrupted version of the update (signed), >> while keeping the same NLRI as before. >> B and C are still signing but not verifying. >> The update propagates via B and C to D. Now D replaces >> this corrupted update with the earlier clean one (received at t0), >> and propagates to E. The resulting update from D to E is valid. >> One can argue that there is violation of the guarantee (in Section 7.1) >> at time t1. The valid route propagated from D to E does not >> agree with the route that B or C forwarded (at time t1) >> for the NLRI in consideration. > >If I understand your scenario correctly, as far as folks further along >the path are concerned, this is a replay attack by D. That D is doing >this to cover up something bad that A is doing to B and C is almost >irrelevant, as is the specific nature of whatever bad thing A is doing >to B and C. > >So, yeah, OK, it's a form of collusion, but it's not one that relies >on a weakness in the signature semantics, it's one that relies on lack >of protection against replay attacks, something the WG discussed and >rejected. Can't speak for anybody else, but I'm not particularly >interested in exhuming the replay horse at this late date. > >___ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
At Thu, 27 Aug 2015 15:45:49 +, Sriram, Kotikalapudi wrote: > > What do you think of the following two-update collusion scenario? > -- > A --> B --> C --> D --> E > A and D are colluding. B and C are signing without verifying. > First update at time= t0: > A signs and forwards an update normally (without any corruption). > The update propagates via B and C to D. > D receives it and stores it, but does not forward to E (or anyone). > Second update at time= t1 (= t0 + delta): > A sends an intentionally corrupted version of the update (signed), > while keeping the same NLRI as before. > B and C are still signing but not verifying. > The update propagates via B and C to D. Now D replaces > this corrupted update with the earlier clean one (received at t0), > and propagates to E. The resulting update from D to E is valid. > One can argue that there is violation of the guarantee (in Section 7.1) > at time t1. The valid route propagated from D to E does not > agree with the route that B or C forwarded (at time t1) > for the NLRI in consideration. If I understand your scenario correctly, as far as folks further along the path are concerned, this is a replay attack by D. That D is doing this to cover up something bad that A is doing to B and C is almost irrelevant, as is the specific nature of whatever bad thing A is doing to B and C. So, yeah, OK, it's a form of collusion, but it's not one that relies on a weakness in the signature semantics, it's one that relies on lack of protection against replay attacks, something the WG discussed and rejected. Can't speak for anybody else, but I'm not particularly interested in exhuming the replay horse at this late date. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
>It appears that this guarantee will not always hold. Specifically, if >two non-adjacent ASes conspire, and they are separated by a sequence of >ASes that sign path data that they have not verified, then the >conspiring ASes can violate the guarantee. Agree with that. What do you think of the following two-update collusion scenario? -- > A --> B --> C --> D --> E A and D are colluding. B and C are signing without verifying. First update at time= t0: A signs and forwards an update normally (without any corruption). The update propagates via B and C to D. D receives it and stores it, but does not forward to E (or anyone). Second update at time= t1 (= t0 + delta): A sends an intentionally corrupted version of the update (signed), while keeping the same NLRI as before. B and C are still signing but not verifying. The update propagates via B and C to D. Now D replaces this corrupted update with the earlier clean one (received at t0), and propagates to E. The resulting update from D to E is valid. One can argue that there is violation of the guarantee (in Section 7.1) at time t1. The valid route propagated from D to E does not agree with the route that B or C forwarded (at time t1) for the NLRI in consideration. >I think this problem might be fixed if we modify the protocol to sign >all of the preceding signed data (rather than just the immediate, >previous signature). If we agree that the above two-update collusion scenario is something we care about, then it should be noted that this fix does not prevent it. Sriram ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
At Wed, 26 Aug 2015 17:26:24 -0400, David Mandelberg wrote: ... > I think this problem might be fixed if we modify the protocol to sign > all of the preceding signed data (rather than just the immediate, > previous signature). Agreed, assuming this means adding the (theoretically invariant) fields from the data to be signed in section 4.1 to the data to be signed in section 4.2. Taking "Origin AS Number" in section 4.1 as equivalent to "Signer's AS Number" in section 4.2, this leaves the algorithm suite identifier, the AFI, the SAFI, and the NLRI to be added to the data to be signed in section 4.2. I doubt that there's any practical attack based on fiddling with the algorithm suite identifier (I'd expect any games there to cause validation failure, end of story), but maybe somebody has a more twisted imagination than mine, and, given that the algorithm suite ID is one byte long, I don't think it's worth trying to optimize that byte out of the section 4.2 signature. Presumably we want to keep the existing signature chaining, so I wouldn't remove anything from the data to be signed in section 4.2, just add the fields that are currently only present in section 4.1. David, if this is consistent with what you meant, cool, if not, say on. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
good catch. one consequence an intermediate AS, which does not validate but signs, could apply prefix-based local policy based on the wrong prefix. same for any bgp4 peers it may have. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
[sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
Hi all, I think I found an issue with draft-ietf-sidr-bgpsec-protocol-13's security guarantees. Apologies that I didn't catch this earlier, before WGLC ended. The security guarantee with the issue is in section 7.1, "For each AS in the path, a BGPsec speaker authorized by the holder of the AS number intentionally chose (in accordance with local policy) to propagate the route advertisement to the subsequent AS in the path." It appears that this guarantee will not always hold. Specifically, if two non-adjacent ASes conspire, and they are separated by a sequence of ASes that sign path data that they have not verified, then the conspiring ASes can violate the guarantee. The ASes that signed path data they didn't verify are behaving properly, since the spec says "In particular, the BGPsec attribute SHOULD NOT be removed even in the case where the BGPsec update message has not been that has not successfully validated." I have not yet been able to come up with a practical attack that uses this issue to do anything particularly bad, but I am concerned that one might exist. I think this problem might be fixed if we modify the protocol to sign all of the preceding signed data (rather than just the immediate, previous signature). Thoughts? -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
