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)" >

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

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

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

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.

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

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

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

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 >>

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

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?

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

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.

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

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

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

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

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,

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,

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

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

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

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

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 ra...@psg.com 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

[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

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

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