Subject: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Wed, 04 Jan 2017 10:30:58 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-sidr-bgpsec-protocol-21: No Objection

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

First, thanks for a well written document!

A few question on the design; not to propose changes but I would like to
learn the reason why the design is as it is:
1) Why do you need to send two different negotiation capabilities for
each direction instead of just using two flags in the same capability?
And similar why don't you just announce multiple address families in the
same capability (using variable length)? 
2) Why are the Secure_Path elements and Signature_Block blocks not
aligned but in two different lists (given there is and one to one
mapping)? Wouldn't it be easier to just update one length field (at a
fixed position) and attached the new information at the end? Or to ask
the question differently: why is the format as shown in figure 8 not used
in the message itself (->this is related to Suresh's question)?

Questions on operation:
1) section 5 says "a BGPsec speaker MAY temporarily defer validation of
incoming BGPsec update messages". 
Does this mean it has to remember its state before applying the update
message such that is can revert to this state if it later detects that
die update message was not valid? Or what action is supposed to happen if
the update message is detected as not valid later on
2) sec 4.2 says "Next, the BGPsec speaker generates one or two
Signature_Blocks." 
Are you sure it's at max 2? I guess this depends on the expected update
cycles of the algorithm compared to the devices. Given update cycles for
devices can be very slow and updates for algorithm can be fast if any
security problems are detected, I wouldn't recommend to limit this to
two.
3) In relation to the comment above, I'm not a big fan of the algo
migration strategy in section 6.1. I understand the problem that all
router on the path need to potentially support the algo. However, you do
have an negotiation phase. So why don't you the advertise the signing
algorithm in the negotiation capabilities? In this case the sender could
at least choose to only send the one(s) that is/are also supported by the
receiver or not use BGPsec at all if there is no match. However, I also
understand that it is probably to late to change anything now and if
there is wg consensus, I'm fine with that...
4) section 8.1 says "the recipient of a valid BGPsec update message is
assured that the update propagated via the sequence of ASes listed in the
Secure_Path portion of the BGPsec_Path attribute."
Is that true? It is assured that at least these ASes have been crossed
but there might have been others on the path that did not sign the
BGPsec_Path attribute, no?
5) Is it really necessary to create registries for "BGPsec Capability"
and "BGPsec_Path Flags"? Given this is a really small number of
bits/flags, I think new RFCs that update this RFC are enough to define a
new use for these so far unused bits.

Further, editorial proposals:
1) I would propose to add the Confed_Segment flag in figure 5 (and call
the remaining flag field 'reserved')
2) Maybe explain Adj-RIB-In or give a reference to RFCrfc4271 section 1.1

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 05 Jan 2017 15:12:58 +0000

> draft-ietf-sidr-bgpsec-protocol-21: No Objection

 [...]

> same capability (using variable length)? 

This is a nit, but I was wondering about this myself.

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Fri, 13 Jan 2017 21:31:28 +0000

Hi Mirja,

Sorry for the delay in replying.

Thank you for your careful review, and the detailed and helpful comments.

Please see my responses inline below marked with [Sriram].

Changes reflecting your suggestions as discussed below

have been incorporated in the forthcoming version-22.

>First, thanks for a well written document!

Thank you.

> A few question on the design; not to propose changes but I would like to learn the reason why the design is as it is:

> 1) Why do you need to send two different negotiation capabilities for each direction instead of just using two flags in the same capability?

> And similar why don't you just announce multiple address families in the same capability (using variable length)?

[Sriram] Oliver Borchert (implementer of one of two available implementations) posted his thoughts on this earlier (responding to a similar question from Russ Housley). He had preference for the way currently it is (please see “To Comment 2” in the link below):

https://www.ietf.org/mail-archive/web/sidr/current/msg08130.html

[Sriram] Also, Keyur and I talked about this issue in a phone call last week. He would have preferred combining those messages (in agreement with you), but thought it was a minor issue and could be left as is for now. He also suggested that if, down the road, router vendor implementers express strong preference for it, a bis can be published. Russ also thought it was minor and was also agreeable to leaving it as is. Please let me know if you still feel strongly.

> 2) Why are the Secure_Path elements and Signature_Block blocks not aligned but in two different lists (given there is and one to one mapping)? Wouldn't it be easier to just update one length field (at a fixed position) and attached the new information at the end? Or to ask the question differently: why is the format as shown in figure 8 not used in the message itself (->this is related to Suresh's question)?

[Sriram] The short answer is that the protocol designers felt that in the bytes sent on the wire, it made sense that the whole Secure_Path should be together and the set of Signatures should be together. For instance, then it is easy to convert Secure_Path to AS_PATH if the update needs to be forwarded unsigned to a non-BGPsec peer. The Secure_Path in its entirety is also used in the checks performed in the list in Section 5.2.

[Sriram] Regarding Figure 8 (format for the data to be hashed), Oliver offered the rationale for it in the following post back when we first made the switch to this format. Michael Baer (implementer of the other available implementation), Oliver, myself, and Matt Lepinski discussed/reviewed it in detail and then we proceeded to include it in the specification.

https://mailarchive.ietf.org/arch/msg/sidr/8B_e4CNxQCUKeZ_AUzsdnn2f5MU

[Sriram] Suresh and Alexey seemed to appreciate the rationale that was applied for the format in Figure 8 (after they read Oliver’s explanation):

https://www.ietf.org/mail-archive/web/sidr/current/msg08237.html

> 1) section 5 says "a BGPsec speaker MAY temporarily defer validation of incoming BGPsec update messages".

> Does this mean it has to remember its state before applying the update message such that is can revert to this state if it later detects that die update message was not valid? Or what action is supposed to happen if the update message is detected as not valid later on

[Sriram] It is left up to an implementation the mechanism for saving the state and returning to where it was left off. If the router deferred validation, it comes back later and completes the validation. If an update message is detected not valid later, the action would be similar to what is done when update validity state change occurs due to an RPKI state change, i.e. re-run best path selection  – see excerpt below (Section 5, p.22):

   For example, when a given RPKI certificate ceases to be valid (e.g.,

   it expires or is revoked), all update messages containing a signature

   whose SKI matches the SKI in the given certificate must be re-

   assessed to determine if they are still valid.  If this reassessment

   determines that the validity state of an update has changed then,

   depending on local policy, it may be necessary to re-run best path

   selection.

> 2) sec 4.2 says "Next, the BGPsec speaker generates one or two Signature_Blocks."

> Are you sure it's at max 2? I guess this depends on the expected update cycles of the algorithm compared to the devices. Given update cycles for devices can be very slow and updates for algorithm can be fast if any security problems are detected, I wouldn't recommend to limit this to two.

[Sriram] This was discussed at an IETF SIDR meeting extensively, and the WG had consensus that two Signature_Blocks would be adequate.

> 3) In relation to the comment above, I'm not a big fan of the algo migration strategy in section 6.1. I understand the problem that all router on the path need to potentially support the algo. However, you do have an negotiation phase. So why don't you the advertise the signing algorithm in the negotiation capabilities? In this case the sender could at least choose to only send the one(s) that is/are also supported by the receiver or not use BGPsec at all if there is no match. However, I also understand that it is probably to late to change anything now and if there is wg consensus, I'm fine with that...

[Sriram] The WG has had consensus on this for quite some time now – that instead of negotiation upfront, the Signature_Block(s) in the update must indicate what algorithm(s) is(are) used.

> 4) section 8.1 says "the recipient of a valid BGPsec update message is assured that the update propagated via the sequence of ASes listed in the Secure_Path portion of the BGPsec_Path attribute."

> Is that true? It is assured that at least these ASes have been crossed but there might have been others on the path that did not sign the BGPsec_Path attribute, no?

[Sriram] Yes, it is true. Each AS in the path MUST sign to the next AS (Target AS). Section 3.1 says:

   The Secure_Path contains one Secure_Path Segment (see Figure 5) for

   each Autonomous System in the path to the originating AS of the

   prefix specified in the update message.

[Sriram] Also, Section 3.2 says:

   A Signature_Block in Figure 6 has exactly one Signature Segment (see

   Figure 7) for each Secure_Path Segment in the Secure_Path portion of

   the BGPsec_Path Attribute.

[Sriram] The following check listed in Section 5.2 make it clear as well:

   3.  Check that each Signature_Block contains one Signature segment

       for each Secure_Path Segment in the Secure_Path portion of the

       BGPsec_Path attribute.  (Note that the entirety of each

       Signature_Block must be checked to ensure that it is well formed,

       even though the validation process may terminate before all

       signatures are cryptographically verified.)

> and "BGPsec_Path Flags"? Given this is a really small number of bits/flags, I think new RFCs that update this RFC are enough to define a new use for these so far unused bits.

[Sriram] This came up in the Russ Housley’s review also. But later he agreed it was OK to include these. He offered some suggestions for clarifying the bits (fields) that were already fully specified in the protocol, and hence didn’t need any IANA consideration. His suggestions were incorporated in the IANA section in version 21.

> 1) I would propose to add the Confed_Segment flag in figure 5 (and call the remaining flag field 'reserved')

[Sriram] Good idea. I have made the change in the forthcoming version-22.

[Sriram] Done. I’ve provided the reference to RFC4271.

Sriram

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 17 Jan 2017 12:05:26 +0100

Hi Sriram,

thanks for your reply. That’s all fine. I really didn’t expect any protocol changes at this late stage of the draft but wanted at least to know if these points were previously discussed. Also happy to see that some parts where discussed with Ross.

One final question (related to point 4): What happens if one router on the path does not support/understand BGPsec? Sorry, if that is a stupid question but it’s still not fully clear to me from the draft…

Mirja

> Am 13.01.2017 um 22:31 schrieb Sriram, Kotikalapudi (Fed) <[email-masked]>:
> 
> Hi Mirja,
>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 17 Jan 2017 15:47:25 +0000

Mirja:

Hi!

If an AS in the path doesn’t support BGPsec, then BGP goes back to “normal” mode (as in before BGPsec), and the assurance that the “update propagated via the sequence of ASes listed” is lost.  In other words, from the origin AS to the AS before the one not supporting BGPsec, we can still provide the assurance, but not beyond that – so any AS including and beyond the one not supporting BGPsec won’t be able to verify anything.

Alvaro.

On 1/17/17, 6:05 AM, "Mirja Kuehlewind (IETF)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sriram,

Mirja
…

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 17 Jan 2017 16:52:25 +0100

Hi Alvaro,

thanks for the very clear clarification. Not sure if it’s just me or if that’s not clearly stated in the draft, but maybe it would be worth it double-checking.

Mirja

> Am 17.01.2017 um 16:47 schrieb Alvaro Retana (aretana) <[email-masked]>:
> 
> Mirja:
>  
> Hi!
>  
>> On 1/17/17, 6:05 AM, "Mirja Kuehlewind (IETF)" <[email-masked]> wrote:
>>  
>> Hi Sriram,
>>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 17 Jan 2017 15:54:15 +0000

ACK

On 1/17/17, 10:52 AM, "Mirja Kuehlewind (IETF)" <[email-masked]<mailto:[email-masked]>> wrote:

---

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

Hi Mirja,

>thanks for the very clear clarification. 
>Not sure if it’s just me or if that’s not clearly stated 
>in the draft, but maybe it would be worth it double-checking.

The draft says the following which covey it (IMO):

Section 2.2, p.5

BGP update messages without the BGPsec_Path attribute MAY be
   sent within a session regardless of whether or not the use of BGPsec
   is successfully negotiated. 

#Sriram: BGP update messages without the BGPsec_Path attribute 
== Traditional BGP update message with AS_PATH
(I should make that substitution in the document for clarity.) 

Top of Section 4.4:

   BGPsec update messages do not contain the AS_PATH attribute.
   However, the AS_PATH attribute can be reconstructed from the
   BGPsec_Path attribute.  This is necessary in the case where a route
   advertisement is received via a BGPsec update message and then
   propagated to a peer via a non-BGPsec update message (e.g., because
   the latter peer does not support BGPsec).

Section 7, p 32. 

   How will migration from BGP to BGPsec look like?  What are the
   benefits for the first adopters?  Initially small groups of
   contiguous ASes would be doing BGPsec.  There would be possibly one
   or more such groups in different geographic regions of the global
   Internet.  Only the routes originated within each group and
   propagated within its borders would get the benefits of cryptographic
   AS path protection.  As BGPsec adoption grows, each group grows in
   size and eventually they join together to form even larger BGPsec
   capable groups of contiguous ASes.  The benefit for early adopters
   starts with AS path security within the contiguous-AS regions spanned
   by their respective groups.  Over time they would see those
   contiguous-AS regions grow much larger.

But I'll see if Alvaro's wording can be additionally 
folded into the document in an appropriate place.

Thank you.

Sriram

________________________________________
From: Mirja Kuehlewind (IETF) <[email-masked]>
Sent: Tuesday, January 17, 2017 10:52 AM
To: Alvaro Retana (aretana)
Cc: Sriram, Kotikalapudi (Fed); [email-masked]; Alexey Melnikov; [email-masked]; The IESG; [email-masked]; Matthias Waehlisch
Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-protocol-21: (with COMMENT)

Hi Alvaro,

Mirja