BGPsec Protocol Specification
draft-ietf-sidr-bgpsec-protocol-23

- I share various people's concerns about the deployability of this protocol, but I realize this is where the WG ended up after many years of work so fingers crossed, I guess.

- Fig 2: Shouldn't the signatures in Sig Block 2 have different identifiers (e.g., X2, Y2) than those in Sig Block 1?

- Sec 6.1: "(likely a small number of years)" -- given how hard these things are to predict, is it wise to include this text here?

- I was surprised not to see an example message or two in this document.

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

Perhaps I'm just having a good day, but this is one of the clearest BGP-related specifications I can remember reviewing. Thanks for that, and especially for the background on design decisions.

I did have questions on two points (which are spread across multiple sections).

I started out wondering why

   Note that BGPsec update messages can be quite large, therefore any
   BGPsec speaker announcing the capability to receive BGPsec messages
   SHOULD also announce support for the capability to receive BGP
   extended messages [I-D.ietf-idr-bgp-extended-messages].

isn't a MUST, but Section 7 explains this 

   In Section 2.2, is was stated that a BGPsec speaker SHOULD announce
   support for the capability to receive BGP extended messages.  Lack of
   negotiation of this capability is not expected to pose a problem in
   the early years of BGPsec deployment.  However, as BGPsec is deployed
   more and more, the BGPsec update messages would grow in size and some
   messages may be dropped due to their size exceeding the current 4K
   bytes limit.  Therefore, it is strongly RECOMMENDED that all BGPsec
   speakers negotiate the extended message capability within a
   reasonable period of time after initial deployment of BGPsec.

Perhaps that's worth a forward pointer? (or maybe even dragging this paragraph forward from Section 7)

I'm looking at 

   BGPsec speakers SHOULD drop
   incoming update messages with pCount set to zero in cases where the
   BGPsec speaker does not expect its peer to set pCount to zero.  (That
   is, pCount is only to be set to zero in cases such as route servers
   or AS Number Migration where the BGPsec speaker's peer expects pCount
   to be set to zero.)

and wondering why that's not a MUST. If I'm understanding this correctly (which is theoretically possible), the BGPsec speaker is telling its peer that it's not participating as a transit AS, but the peer thinks it should be. Is there anything intelligent that the peer can do with the update?

Section 7 refers to this SHOULD, while adding a few more SHOULDs. 

   A peer that is an Internet Exchange Point (IXP) (i.e.  Route Server)
   with a transparent AS is expected to set pCount = 0 in its
   Secure_Path Segment while forwarding an update to a peer (see
   Section 4.2).  Clearly, such an IXP SHOULD configure itself to set
   its own pCount = 0.  As stated in Section 4.2, "BGPsec speakers
   SHOULD drop incoming update messages with pCount set to zero in cases
   where the BGPsec speaker does not expect its peer to set pCount to
   zero."  This means that a BGPsec speaker SHOULD be configured so that
   it permits pCount =0 from an IXP peer and never permits pCount = 0
   from a peer that is not an IXP.

Again, I'm curious about why a BGPsec speaker wouldn't do this. Is that obvious, to those skilled in the art?

I'm looking at Section 8.4, which adds some more background.

   The mechanism of setting the pCount field to zero is included in this
   specification to enable route servers in the control path to
   participate in BGPsec without increasing the length of the AS path.
   However, entities other than route servers could conceivably use this
   mechanism (set the pCount to zero) to attract traffic (by reducing
   the length of the AS path) illegitimately.  This risk is largely
   mitigated if every BGPsec speaker drops incoming update messages that
   set pCount to zero but come from a peer that is not a route server.
   However, note that a recipient of a BGPsec update message within
   which an upstream entity two or more hops away has set pCount to zero
   is unable to verify for themselves whether pCount was set to zero
   legitimately.

So, the reason this is a SHOULD, and not a MUST, is because a recipient two or more hops away can't be sure pCount was set appropriately? But doesn't the SHOULD increase the chances to propagate an update with an inappropriate pCount?

* Section 2.1

The IANA registry at http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml may be a better reference for AFIs than RFC4760.

* Section 4.2

Is there a specific reason that the signature construction algorithm orders the fields in the way it does? It does look pretty complicated to parse out and arrange the fields this way from the BGPsec packet that was received.  Something like the following seems much simpler to calculate

         +------------------------------------+
         | Target AS Number                   |
         +------------------------------------+ ---\
         | Signature Segment   : N-1          |     \
         +------------------------------------+     \
                ...                                 |
         +------------------------------------+     |
         | Signature Segment   : 2            |     |
         +------------------------------------+     |
         | Signature Segment   : 1            |     \
         +------------------------------------+      >  Data from
         | Secure_Path Segment : N            |     /   N Segments
         +------------------------------------+     |
                ...                                 |
         +------------------------------------+     |
         | Secure_Path Segment : 2            |     |
         +------------------------------------+     /
         | Secure_Path Segment : 1            |    /
         +------------------------------------+---/
         | Algorithm Suite Identifier         |
         +------------------------------------+
         | AFI                                |
         +------------------------------------+
         | SAFI                               |
         +------------------------------------+
         | Prefix                             |
         +------------------------------------+

as the segment fields and signature fields are naturally grouped together in the packet. Is there a difference in cryptographic strength between these two constructions?