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

[Ballot discuss]


I have a couple of fairly straightforward things I'd
like to briefly discuss...

(1) 3.2/Figure 7: A fixed 20 byte SKI being a sha-1 hash
of the public key is a bad plan, for all the usual
reasons. Why is it ok for that to be hardcoded here when
it could change if/when new alg choices are made for the
RPKI? If it is not too late then I think you should add a
length or alg field to that. If it is too late to do that,
then are we really ok that you will need to rev the BGPsec
version number in order to get rid of all sha-1 code from
your implementation? That seems like a bad plan for a new
protocol.

(2) Cleared

(3) section 8: Is there a potential exposure here in that
a relying party who emits e.g.  certificate status checks
or cert retrieval queries for an RPKI cert they've not
previously seen is exposing something about the set of
paths its traffic is likely to follow. (This is similar to
why we have OCSP stapling in the web.) IIRC the RPKI specs
may cover this but I suspect it'd be worth noting here as
well even if so as this represents exposing something
about BGP announcement content to off-path parties which I
think is new for BGP. Is that a new thing for BGP? (I
think the new aspect to the attack is that a bad actor who
has already compromised some AS could more easily spot
that traffic from the relying party's AS is likely to
transit the compromised AS.)

[Ballot 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.

[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.)]

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

[Ballot 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.

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

[Ballot comment]
- 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.

[Ballot comment]
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?

[Ballot discuss]


I have a couple of fairly straightforward things I'd
like to briefly discuss...

(1) 3.2/Figure 7: A fixed 20 byte SKI being a sha-1 hash
of the public key is a bad plan, for all the usual
reasons. Why is it ok for that to be hardcoded here when
it could change if/when new alg choices are made for the
RPKI? If it is not too late then I think you should add a
length or alg field to that. If it is too late to do that,
then are we really ok that you will need to rev the BGPsec
version number in order to get rid of all sha-1 code from
your implementation? That seems like a bad plan for a new
protocol.

(2) Figure 8: It seems to me to be an error to omit the
signer's ASN from the signed data and only have that
included in the signer's certificate. Why is that intimate
level of binding to the RPKI desirable? There may well be
reasons but I'm not seeing 'em, and I am recalling that it
took a chunk of effort to make CMS less dependent on
X.509 for similar reasons (meaning identifying signers
exclusively via cert issuer and serial in that case).  I
would expect that there could be demand to have some level
of independence between BGPsec and RPKI for at least
internal uses such as those noted in the spec already.

(3) section 8: Is there a potential exposure here in that
a relying party who emits e.g.  certificate status checks
or cert retrieval queries for an RPKI cert they've not
previously seen is exposing something about the set of
paths its traffic is likely to follow. (This is similar to
why we have OCSP stapling in the web.) IIRC the RPKI specs
may cover this but I suspect it'd be worth noting here as
well even if so as this represents exposing something
about BGP announcement content to off-path parties which I
think is new for BGP. Is that a new thing for BGP? (I
think the new aspect to the attack is that a bad actor who
has already compromised some AS could more easily spot
that traffic from the relying party's AS is likely to
transit the compromised AS.)

[Ballot comment]

- (Non actionable comment really aimed at the IESG and not
the authors/WG...) I'm kinda sad that even today we don't
appear to have learned to value deploy-ability more highly.
I fear that BGPsec and RPKI will suffer a similar lack of
deployment as seen with S/MIME and DNSSEC and for possibly
similar reasons (complexity, not starting with modest
improvements, requiring a number of parties to change
before seeing benefits).  I hope I'm wrong about that, but
equally, if I'm not and RPKI/BGPsec deployment turns out
to be very very slow, (as opposed to the optimistic, "just
slow";-) then I also hope the IESG at that time will be
willing to consider alternatives - it's too easy for the
IETF to just get stuck when a technology like this fails
to deploy. But maybe I'm wrong and this'll all be fine and
will be widely deployed and used in a few years.

- Figures 2 and 5 present the fields in different orders.
That seems like a bad idea.

- 3.2: The reference to the pki profile doc is not precise
enough, the string "key identifier" does not occur in that
draft - it's in RFC6487, 4.8.2.

- 4.1, last para: is the distinction between an "internal
peer" and "iBGP peer" sufficiently clear to routing folk?
For me they sound similar but I assume it's ok.

- 5.2, I think you need to say something to the effect
that every Secure_Path MUST have a signature with an
algorithm that is supported. As I read the text, the
algorithm as stated here could be read to not require
that. E.g. the para before the bullets on p25 could be
read to mean "drop all stuff involving unsupported algs
and then continue to process the rest of the stuff."

- section 7: WRT non-deterministic signature algorithms, I
think it'd be useful to note here that all such algorithms
require good random number generation on the signer's
system and that failing in that respect can expose the
signer's private key.  IMO deterministic signature schemes
are better for this reason but the need for a good RNG is
I think a real operational issue worthy of note.

[Ballot comment]
+1 to the comment from Suresh about order. I though that something like what he proposed will minimize memcopies and possibly use of memory why hashing. So I am also curious to know answer to his question.

Otherwise the document is very well written and it was a pleasure to read!

[Ballot comment]
* 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?

[Ballot comment]
1) Sec 2.1: "  The fifth bit of the first octet is a direction bit which indicates
  whether the BGP speaker is advertising the capability to send BGPsec
  update messages or receive BGPsec update messages.  The BGP speaker
  sets this bit to 0 to indicate the capability to receive BGPsec
  update messages.  The BGP speaker sets this bit to 1 to indicate the
  capability to send BGPsec update messages."

  How does a BGP speaker indicate the ability to both send and receive BGPsec update messages?
  I see that it is specified in Sec 2.2 and that is also where the assumption is that multiple capabilities
  with the same version can be sent.  Please clarify in Sec 2.1 that it is expected to send multiple capabilities
  with the same (as well as different) versions.

[Ballot comment]
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 are the signing algorithm not advertised in the negotiation capabilites (instead)? In this case the sender could 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.
2) Why do you need to send two different negotiation capabilites for each direction instead of just using two flags in the same capability? And similar why don't you just announce muliple address families in the same capability (using variable length)?
3) If differnet versions are supported, would you send capabilities with differnet version numbers in the same advertisement?
4) 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?

Further, editorial proposals:
1) I would propose to add the Confed_Segment flag in figure 5 (and call the remaining flag field 'reserved')
2) sec 4.2: "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 ofr devices can be very slow and update for algorithm can be fast if any security problems are detected, I wouldn't recommend to limit this to two.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-sidr-bgpsec-protocol-19.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the Capability Codes located at:

https://www.iana.org/assignments/capability-codes/

a new code is to be registered as follows:

Value: [ TBD-at-registration ]
Description: BGPsec Capability
Reference: [ RFC-to-be ]

The value assigned will come from the BGP Capabilities Code registry's "IETF Review" range.

Second, in the BGP Path Attributes subregistry of the Border Gateway Protocol (BGP) Parameters registry located at:

https://www.iana.org/assignments/bgp-parameters/

a new path attribute is to be registered as follows:

Value: [ TBD-at-registration ]
Code: BGPsec_Path
Reference: [ RFC-to-be ]

Third, a new registry is to be created called the BGPsec Capability registry. This new registry will be a subregistry of the Resource Public Key Infrastructure (RPKI) registry located at:

https://www.iana.org/assignments/rpki/

The new registry will be managed through Standards Action as defined in RFC 5226. There are initial values for the new registry as follows:

+------+---------------+---------------+
| Bits | Field | Reference |
+------+---------------+---------------+
| 0-3 | Version | [ RFC-to-be ] |
| +---------------+---------------+
| | Value = 0x0 | [ RFC-to-be ] |
+------+---------------+---------------+
| 4 | Direction | [ RFC-to-be ] |
+------+---------------+---------------+
| 5-7 | Unassigned | [ RFC-to-be ] |
+------+---------------+---------------+

Fourth, a new registry is to be created called the BGPsec_Path Flags registry. This new registry will also be a subregistry of the Resource Public Key Infrastructure (RPKI) registry located at:

https://www.iana.org/assignments/rpki/

The new registry will be managed through Standards Action as defined in RFC 5226. There are initial values for the new registry as follows:

+------+---------------------------+---------------+
| Flag | Description | Reference |
+------+---------------------------+---------------+
| 0 | Confed_Segment | [ RFC-to-be ] |
+------+---------------------------+---------------+
| 1-7 | Unassigned (set to zeros) | |
+------+---------------------------+---------------+

The IANA Services Operator understands that these four actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-sidr-bgpsec-protocol@ietf.org, sidr-chairs@ietf.org, "Matthias Waehlisch" , sidr@ietf.org, aretana@cisco.com, m.waehlisch@fu-berlin.de
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (BGPsec Protocol Specification) to Proposed Standard


The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'BGPsec Protocol Specification'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-12-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes BGPsec, an extension to the Border Gateway
  Protocol (BGP) that provides security for the path of autonomous
  systems through which a BGP update message passes.  BGPsec is
  implemented via an optional non-transitive BGP path attribute that
  carries a digital signature produced by each autonomous system that
  propagates the update message.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ballot/


No IPR declarations have been submitted directly on this I-D.

== AD Review of draft-ietf-sidr-bgpsec-protocol-18 ==

I have several comments (see below).  For the most part, I think they should be easy to solve as many are related to clarifications.  Most of the comments I classified as Major are due to the use of Normative language.

The biggest concern I have with this document is the lack of an Operations and Management Considerations Section – please take a look at RFC5706 (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions).  Some of the information suggested there is present in draft-ietf-sidr-bgpsec-ops, and (ironically) in the “Design and Deployment Considerations” section of draft-ietf-sidr-bgpsec-overview.  However, important items such as migration or management are missing.  I would like to see a well thought out Operations and Management Section in this document before moving it forward.  Note that I’m not suggesting that a YANG model (for example) is required to move forward, but I would like to see considerations about migration, and the impact on network operations, to mention two items, all in one place in the document.  I would like the authors/Chairs/Shepherd/WG to consider even merging in draft-ietf-sidr-bgpsec-ops as the base for this new section (or at least reference it prominently).

Thanks!

Alvaro.



Major:

M1. Registry Definitions

M1.1. Section 2.1. (The BGPsec Capability) includes a Version field and some Reserved bits, but there are no IANA registries defined for how to manage these spaces.  Please define the registries and the corresponding registration procedures.

M1.2. Section 3.1. (Secure_Path) defines the Flags field and assigns the first bit (BTW, is that the MSB or the LSB, please clarify), but doesn't set up the registry or registration procedures.



M2. Error Handling — Several sections don't have proper error handling procedures specified. (This is a management issue that I think is underspecified.)

M2.1. Section 2.2. (Negotiating BGPsec Support) doesn't fully specify the error handling behavior of the Capability, and it fails open.

M2.1.1. What should the action be if the Version is not 0?

M2.1.2. "…a BGP speaker MUST NOT advertise the capability of BGPsec support for a particular AFI unless it has also advertised the multiprotocol extension capability for the same AFI [RFC4760]."  What should happen if it does advertise an AFI that is not covered by the multiprotocol extension capability?  Or if the multi-protocol capability is not advertised at all?  To clarify: if the multi-protocol capability is not advertised then support for BGPsec can’t be advertised either – does that mean that a BGP speaker configured to use BGPsec must not use it if not negotiated?  I know the answer is “yes”, but I’m trying to get to the point of provisioning and expectations – why configure BGPsec if no one is expected to support it?

M2.1.3. Missing the four-byte AS capability results in BGPsec not working ("BGPsec has not been successfully negotiated"), but the ability of exchanging routes is still there, leaving the system in a fail open state and potentially breaking the chain of ASNs.  Personally, it doesn't seem like a good result — please at least include some text about this in the Security Considerations section.


M2.2. The definition of the BGPsec_Path Attribute (and its details) don't have clear error handling procedures defined (RFC7606).  Section 4.3. (Processing Instructions for Confederation Members) does say this: "(As discussed in Section 5.2, any error in the BGPsec_Path attribute MUST be handled using the "treat-as-withdraw", approach as defined in RFC 7606 [RFC7606].)" (including the parentheses).  However, 5,2 only says: "BGPsec speakers MUST handle these errors using the "treat-as-withdraw" approach as defined in RFC 7606 [RFC7606]."  Note: "these errors" is not the same as "any error".  Please discuss error handling in a more prominent place. (Hint: it may fit in a fault management discussion in the Operations and Management Section.)

M2.2.1. There are multiple places in the BGPsec_Path Attribute that could end up in an error, everything from setting bits in the Flags field to wrong Length fields.  Should all errors result in the same behavior?



M3. Section 4.1. (General Guidance): "When propagating a received route advertisement to an internal peer, the BGPsec speaker typically populates the BGPsec_Path attribute by copying the BGPsec_Path attribute from the received update message.  That is, the BGPsec_Path attribute is copied verbatim…. Note that when a BGPsec speaker chooses to forward a BGPsec update message to an iBGP peer, the BGPsec attribute SHOULD NOT be removed, unless the peer doesn't support BGPsec."  The first part of the guidance says that a new BGPsec_Path attribute is created by copying the received attribute (which is then presumably removed), but the second part says that the received attribute SHOULD NOT be removed.  Please clarify so that there is consistency -- I understand that the result is the same, but the description is not and we should try to avoid confusion.  Parts of Section 4.2. (Constructing the BGPsec_Path Attribute) also talk about actions like "…and there is an existing BGPsec_Path attribute, then the BGPsec speaker prepends its new Secure_Path Segment (places in first position) onto the existing Secure_Path", which hint at propagating a received BGPsec_Path attribute (and not creating a new one).



M4. Section 4.2. (Constructing the BGPsec_Path Attribute) says that "The AS number in this Secure_Path segment MUST match the AS number in the AS number resource extension field of the Resource PKI router certificate(s) that will be used to verify the digital signature(s) constructed by this BGPsec speaker [I-D.ietf-sidr-bgpsec-pki-profiles]."  However, there is no extension field or certificate in I-D.ietf-sidr-bgpsec-pki-profiles with that name.  Please be precise with the names.



M5. In 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 text seems to assume some kind of configuration/provisioning.  Note that Section 5.2. (Validation Algorithm) also has similar text about receiving an UPDATE “from a peer that is not expected to set pCount equal to zero”.



M6. In 4.2: “If the received BGPsec update message contains two Signature_Blocks and the BGPsec speaker supports both of the corresponding algorithm suites, then the new update message generated by the BGPsec speaker SHOULD include both of the Signature_Blocks.”  Why is this “SHOULD” not a “MUST”?  When/why would a speaker remove one or the 2?  If one is removed, should there be a requirement that the one that was used to successfully validate the update be kept?  Note that Section 7.2 later talks about the problems of removing signatures…

M6.1. Note that later in this section the text says that “a 'Valid' BGPsec update message may contain a Signature_Block which is not deemed 'Valid' (e.g., contains signatures that BGPsec does not successfully verify).  Nonetheless, such Signature_Blocks MUST NOT be removed.”  Taking this “MUST NOT” along with the “SHOULD” above, the door is open to remove the Signature_Block used to verify the validity and just forward the one not used (which may itself not be valid).

M6.2. Section 5.2. (Validation Algorithm) opens this door even more when saying that “If at least one Signature_Block is marked as 'Valid', then the validation algorithm terminates and the BGPsec update message is deemed to be 'Valid'.”  The text here doesn’t require that both Signature_Blocks be verified, but implies that as long as the first one is valid then the second one doesn’t really need to be verified.  Is that the intent?



M7. Section 5. (Processing a Received BGPsec Update) talks about “duplicate update messages” (one where “it differs from the first update message only in the Signature fields (within the BGPsec_Path attribute)”).

M7.1. “With regards to the processing of duplicate update messages, if the first update message is valid, then an implementation SHOULD NOT run the validation procedure on the second, duplicate update message (even if the bits of the signature field are different).”  Even though a discussion about non-deterministic signature algorithms precedes this text, the validation is still not run.  How can the validity of the Path be guaranteed in this case?  Should this be the action for all algorithms or only ones known to be non-deterministic?

M7.2. rfc4271 (in Section 9. (UPDATE Message Handling) talks about the implicit withdraw of a route “if the NLRI of the new route is identical to the one the route currently has stored…”.  The same NLRI case seems to be a particular condition of the “duplicate update” described here.  It might be a good idea to mention that a “duplicate update” results in the implicit withdraw of the original update.  What happens if a third duplicate route is received (the first one was valid, the second one was not validated), should it be validated?



M8. Section 5.1. (Overview of BGPsec Validation) says that "BGPsec specifies no changes to the BGP decision process."  However, Section 5. (Processing a Received BGPsec Update) also says that "a BGPsec speaker MUST utilize the AS path information in the BGPsec_Path attribute in all cases where it would otherwise use the AS path information in the AS_PATH attribute."  I'm assuming that the Decision Process is included in "all cases".  Even though 5.1 refers to the use the validation state in the decision process, please make sure that it is clear that the decision process is modified by the use of the different attribute.

M8.1. Please specifically include a section (or text somewhere) about how the information in the BGPsec_Path attribute is used in the Decision Process.  For example, how should the "number of AS numbers" in the path be calculated for 9.1.2.2. (Breaking Ties (Phase 2)) in rfc4271?  The text talks about the "effective length" being the sum of the pCount values, but the "effective length" (at least with that name) is not what is used in rfc4172 — please be clear and consistent.

M8.2. [minor] Section 3. (The BGPsec_Path Attribute) reads: "The information in Secure_Path is used by BGPsec speakers in the same way that information from the AS_PATH is used by non-BGPsec speakers."  This is pretty much the same information that is in Section 5, but with more specificity.  It would help if the more specific case was the one normatively called out.



M9. Section 5.2. (Validation Algorithm).  RFC4271 also specifies a series of validity checks when an UPDATE is received (Section 6.3) – should that check be run before or after the algorithm specified here?  The algorithm focuses on verifying the validity of the BGPsec_Path attribute (and not the whole UPDATE), so I’m assuming it should be executed instead of checking the AS_PATH.  Please include some text about the interaction/changes.

M9.1.  Section 5.2. (Validation Algorithm): “…then the BGPsec speaker MUST treat the update message in the same manner that the BGPsec speaker would treat an (unsigned) update message that arrived without a BGPsec_Path attribute.”  What exactly does this mean?  If the BGPsec_Path attribute is not received, then the AS_PATH should be – does the text imply that the AS_PATH should be reconstructed?  I guess it should be if the update is to be propagated – but the question is while the update is being processed, which AS path information is used, the one in a reconstructed AS_PATH or the one in the BGPsec_Path while assuming that all the signatures are correct?



M10.  In Section 7.2. (On the Removal of BGPsec Signatures): “…the protocol specifies that a BGPsec speaker choosing to propagate the route advertisement in such an update message SHOULD add its signature to each of the Signature_Blocks.”  I believe the reference is Section 4.2 (please add it).  However, that Section doesn’t use normative language (“For each Signature_Block corresponding to an algorithm suite that the BGPsec speaker does support, the BGPsec speaker adds a new Signature Segment to the Signature_Block.”)  In any case, the “SHOULD” in 7.2 is out of place because it is referencing a fact (pointing at the other section) and not being used normatively – if you want the “SHOULD” to be normative, then it should be back in 4.2.


M11. The Figures (which are not numbered) in 4.2. (Constructing the BGPsec_Path Attribute) and 5.2. (Validation Algorithm) present the sequence of octets to be hashed.  I’m guessing that the order of the Signature and Secure_Path Segments may be important, is it?  The order in the Figures is not clear to me, if the order is important, please be clear about it; if not, please also say so.



M12. The mandatory addition of Secure_Path and Signature segments in a Confederation results in the inconsistent authorization chain mentioned in Section 4.3. (Processing Instructions for Confederation Members): “For a signature produced by a peer BGPsec speaker outside of a confederation, the Target AS will always be the AS Confederation Identifier (the public AS number of the confederation) as opposed to the Member-AS Number.”  It seems to me that this discontinuity in the ASN list breaks the “cryptographic assurance that…Every AS on the path of ASes listed in the update message has explicitly authorized the advertisement of the route to the subsequent AS in the path” because there is no way to verify that the Member-AS in the first Secure_Path segment is in fact the one peering with the external neighbor.  I realize that the risk may be minimized by an “internal trust” factor, but I would like to see a discussion about this issue in the Security Considerations.



M13. What about replay attacks?  There is no mention of the risk or potential mitigation anywhere.  Please include in the Security Considerations section.



Minor:

m1. The use of SKI, Subject Key Identifier without a qualifier (field, extension) is confusing at times.  Please expand SKI on first use.  An example: (from 3.2) “The Subject Key Identifier contains the value in the Subject Key Identifier extension of the RPKI…”  The first mention should include “field”, like similar text in 4.2.


m2. Section 4. (BGPsec Update Messages) says: "A BGPsec speaker that is not a member of such a confederation MUST set the Flags field of the Secure_Path Segment to zero in all BGPsec update messages it sends."  While only one flag is defined, the correct statement is "…set the Confed_Segment flag…".


m3. Section 4.1. (General Guidance): s/"A BGPsec update message MUST advertise a route to only a single NLRI."/"A BGPsec update message MUST advertise a route to only a single prefix."  This section contains other places where the NLRI term is not used correctly.  In short, the NLRI in a BGP Update contains one or more prefixes — so the text should talk about a single prefix, not a single NLRI.


m4. In between the text above, the following is written: "However, in the case that the BGPsec speaker is performing an AS Migration, the BGPsec speaker may add an additional signature on ingress before copying the BGPsec_Path attribute (see [I-D.ietf-sidr-as-migration] for more details)."  Because I-D.ietf-sidr-as-migration is marked as Updating this document, I suggest you remove this text (and the one in 4.2) -- note that the statements made in this document are not normative anyway and I-D.ietf-sidr-as-migration can stand on its own by clearly specifying what is needed for AS Migration.


m5. In 4.2: “To prevent unnecessary processing load…a BGPsec speaker SHOULD NOT produce multiple consecutive
Secure_Path Segments with the same AS number.  This means that to achieve the semantics of prepending the same AS number k times, a BGPsec speaker SHOULD produce a single Secure_Path Segment – with pCount of k...”  Given pCount, I’m wondering why these SHOULDs are not MUSTs, especially given the expected additional load.


m6. Section 4.3. (Processing Instructions for Confederation Members) explains the process of adding Secure_Path and Signature segments that may or may not be used at all (given that the verification is optional), only to remove them later.  Why isn’t the process of adding Secure_Path and Signature segments optional itself (instead of just the validation)?


m7. In 4.4. (Reconstructing the AS_PATH Attribute), what should happen if the Confed_Segment flag is set to zero and the most-recently added segment in the AS_PATH is of type AS_CONFED_SEQUENCE?  Theoretically this can’t occur because it means that someone accepted an update that it shouldn’t have, but please include some text about this case being an error.


m8. Section 5.1. (Overview of BGPsec Validation): “It is expected that BGP peers will generally prefer routes received via 'Valid' BGPsec update messages over both routes received via 'Not Valid' BGPsec update messages and routes received via update messages that do not contain the BGPsec_Path attribute…(See [I-D.ietf-sidr-bgpsec-ops]…”  I read this piece of text as saying that routes in Not Valid updates are expected to be used (even though they are not valid).  Besides the fact that I-D.ietf-sidr-bgpsec-ops does recommend using Not Valid announcements (in Section 7), are there other reasons for this document to expect their use?


m9. Section 5.1 contains these references: “…the trusted cache could deliver the necessary validity information to the BGPsec speaker using the router key PDU [I-D.ietf-sidr-rtr-keying] for the RPKI-to-Router protocol [I-D.ietf-sidr-rpki-rtr-rfc6810-bis].”  The reference to I-D.ietf-sidr-rtr-keying seems to be related to the “router key PDU”, but that is defined in I-D.ietf-sidr-rpki-rtr-rfc6810-bis, so it looks like the first reference is not needed.


m10. In 5.1: “As discussed in Section 4, when a BGPsec speaker chooses to forward…, it SHOULD be forwarded with its BGPsec_Path attribute…”  That “SHOULD” is pointing at a fact, not acting normatively in this sentence so please change it to “should”.


m11. Section 5.2. (Validation Algorithm) mentions this check: ‘update..from a peer that is not a member of the BGPsec speaker's AS confederation, check to ensure that none of the Secure_Path segments contain a Flags field with the Confed_Sequence flag set to one.”  I’m sure that the check for the flag set if the peer is a Confederation peer is also needed, but not mentioned in this section (where the normative MUST for the validation algorithm) is present.  Section 4.3. (Processing Instructions for Confederation Members) does say this: “…when a confederation member runs the algorithm in Section 5.2, the confederation member, during processing of a Signature Segment, first checks whether the Confed_Sequence flag in the corresponding Secure_Path segment is set to one.”  I would like to see the full algorithm specified in one place (even if, like in Section 4.3, pieces of it are explained elsewhere).  Also, the text in 4.3 says that the check is performed “during processing of a Signature Segment”, which is fine, but probably late in the process (compared to the text in 5.2 that seems to require the check when the updates are received).


m12. In Section 7.4. (Additional Security Considerations), please add a reference to point at “appropriate transport security mechanisms.”, and/or point at the Security Considerations from rfc4271.



Nits:

n1. In several places the text uses “we” (for example: “we expect…”).  It’s just a matter of style, but using the third person may be more appropriate (for example: “it is expected…”).

n2. The use of “Target AS Number” is inconsistent: sometimes the “number” is capitalized, others it isn’t, and sometimes it is not even mentioned.

n3. I don’t think we need Section 6.2. (Extensibility Considerations).

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 14 June 2016.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  The draft requested status is Standards Track, as indicated on the title
  page. After an extensive discussion, WG members concluded that Proposed Standard
  would be appropriate mainly because of the following arguments:

  The design of BGPsec is based on more than 15 years of analysis,
  including more than five years of protocol engineering, discussions, and
  revisions in the IETF. In particular, the original design evolved to
  accommodate real-world routing deployment topics. As such, BGPsec is
  generally stable, has resolved known design choices, and is believed to
  be well-understood.

  BGPsec is the successor of the origin validation standards. Changing the
  track to Experimental will limit adoption.

  A critical amount of the community seems to think that BGPsec is a
  promising approach that merits Proposed Standard.

  Several implementations are available (details see below).

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  BGPsec describes a security extension to the Border Gateway Protocol
  (BGP). This extension provides functionality to verify the integrity of
  the AS path within an BGP update message. It thus enables a BGP speaker
  to check if the update message has been traversed along the AS path as
  listed in the update message.

  To implement the proposed functionality, BGPsec replaces the existing
  AS_PATH attribute by an BGPsec_Path attribute, specifies a BGPsec update
  message, and relies on the Resource Public Key Infrastructure (RPKI) for
  provision of router certificates.

Working Group Summary

  This document has been discussed in the working group since 2011. The WG
  has been asked periodically to confirm continued interest, and has each
  time indicated that the work is valuable and should continue.
  Publication of this document will conclude milestone "Publication:
  Document the BGP protocol enhancements that meet the security
  requirements" of the SIDR working group.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

  The work mentioned here is applicable to all inter-domain BGP operators.
  BGPsec has been implemented in BIRD and Quagga, two popular open source
  BGP daemons. The BIRD community explicitly agreed to integrate this
  extension in the main branch.

  The document has undergone three working group last calls. During the
  first and second WGLC Wes George gave extensive feedback. David
  Mandelberg identified a syntax problem during the second WGLC.

  After the second call was passed and a revised version has been
  submitted, David Mandelberg identified a problem with security
  guarantees, which led to protocol changes in the subsequent version.

  After that Oliver Borchert and Michael Baer proposed to change the .
  Sequence of Octets to be Signed. The proposed changes were based on
  implementation experiences to enable the validation of the complete
  chain of signatures in an update. This was the last normative change.

  During the third WGLC no normative changes have been requested.

  John Scudder provided substantial editorial feedback.

  The Inter-Domain Working Group was also asked for feedback during the
  different WGLCs.

  No expert review was required.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  Shepherd: Matthias Waehlisch
  Responsible AD: Alvaro Retana

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd has reviewed the document, identified a few
  ambiguities which have been resolved with the authors.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.  This document has been carefully reviewed by the WG multiple times.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  There is no need for a broader review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  The document shepherd has no concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  The document authors have all confirmed they know of no needed
  IPR disclosures.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There is no IPR disclosure filed for this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  The WG has confirmed more than once that they are interested
  in this work and have reviewed it multiple times.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  There has been neither threat of an appeal nor extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The idnits tool reports no errors.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  The document has no content that requires formal review.

(13) Have all references within this document been identified as
either normative or informative?

  Yes, the references are identified as either normative or informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  References [8]-[10] are normative references and currently Internet
  drafts. They are being requested to be published at the same time as
  this draft, or are past WGLC and are waiting for writeup in the IDR
  working group.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  The idnits tool reports no downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No, the publication of this document will not change the status of any
  existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  This document registers a new capability in the registry of BGP
  Capabilities. The description for the new capability is "BGPsec
  Capability".

  Furthermore, this document registers a new path attribute in the
  registry of BGP Path Attributes. The code for this new attribute is
  "BGPsec_PATH".

  The registries are clearly identified, the values are consistent
  with the text, all extensions are noted for registration in the
  proper registries.  No new IANA registries are created.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new IANA registries are created by this document.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  There are no sections of the document written in a formal language.