Subject: [sidr] Ben Campbell's Yes on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Wed, 04 Jan 2017 13:43:48 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-sidr-bgpsec-protocol-21: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I share some of the concerns about deployability, but have nothing new to
add to that conversation. Otherwise I just have a few minor comments:

-2: draft-ietf-sidr-bgpsec-protocol explicitly excludes non-capitalized
versions of 2119 words. This draft does not. It seems different 2119
approaches among the various bgpsec draft could be confusing to the
reader.

- 5.2, step 2: I'm almost sure I've missed something here, but if I
understand correctly, previous sections talked about how a peer can
propagate a BGPsec_Path attribute without modification. Will that cause a
problem in this step if the immediate peer propagated an unmodified
BGPsec_Path that came from a different AS? 

- 8.4, last paragraph: The text describes a replay attack, and delegates
the mitigation solution to draft-ietf-sidr-bgpsec-rollover. This is an
informational reference; it seems like it should be normative.

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Sat, 14 Jan 2017 17:23:27 +0000

Hi Ben,

Sorry for the delay in responding. 
Thank you for the review and very helpful comments.
Please see my responses inline below.
The changes mentioned below that reflect your comments/suggestions
are already incorporated in the forthcoming version-22. 

>  [Update: Oops, sorry,  I meant to say draft-ietf-sidr-bgpsec-ops excludes
>  non-capitalized versions of 2119 words. (That is to say, it treats them
>  as their normal English equivalents.)]

Thank you for pointing this out. I have gone over the whole document 
and wherever the standards language [RFC 2119] is applicable, 
I have made sure that upper case “MUST”, “SHOULD” etc. are used
rather than lower case “must”, “should” etc.

>  BGPsec_Path that came from a different AS?

You are right in pointing this out. The key is that 5.2, step 2 
check is meant to be done with eBGP peer (not iBGP).
Unmodified BGPsec update is sent only to 
BGPsec-capable iBGP peers (internal peers).
In the case of an eBGP (BGPsec capable) peer, the BGPsec update is always 
modified and propagated with a new Secure_Path Segment and Signature added.
So I have modified the wording in 5.2, step 2 to read as follows:

   2.  Check that AS number in the most recently added Secure_Path
       Segment (i.e. the one corresponding to the eBGP peer from which
       the update message was received) matches the AS number of that
       peer as specified in the BGP OPEN message.  (Note: This check is
       performed only at an ingress BGPsec router where the update is
       first received from a peer AS.)

>  the mitigation solution to. This is an
>  informational reference; it draft-ietf-sidr-bgpsec-rollover 
>seems like it should be normative.

The solution for mitigation of replay attacks is out of band
(in relation to the BGPsec protocol). 
As I see it, draft-ietf-sidr-bgpsec-rollover proposes 'a way'
of replay attack mitigation. Techniques for key rollover / 
replay attack mitigation are expected to continue to evolve. 
There are various variants of the basic key rollover technique that 
are discussed in this informational draft:
https://tools.ietf.org/html/draft-sriram-replay-protection-design-discussion-07 
What needs to be pointed out in the BGPsec specification is that 
there are solutions available for replay attack mitigation. 
The above are the reasons why 
draft-ietf-sidr-bgpsec-rollover is included in informational references. 

Sriram

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 17 Jan 2017 13:34:40 -0600

Thanks for the response. I have one remaining comment, below. I removed 
sections that I think are resolved.

Thanks!

Ben.

> draft-ietf-sidr-bgpsec-rollover is included in informational 

That is a reasonable response, if you think it is realistic that people 
would implement solutions other than the one in the reference. It would 
help if the text were more clear that draft-ietf-sider-bgpsec rollover 
is an example of a possible solutions, and other solutions are possible.

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 18 Jan 2017 03:54:36 +0000

Ben,

Thank you. Please see my response inline below.

>is an example of a possible solutions, and other solutions are possible.

I will try to edit the text a bit to make that clear when I have the next
opportunity to edit the document. 

Sriram