Subject: [sidr] comments on draft-ietf-sidr-bgpsec-protocol

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 26 Sep 2012 17:43:14 +0000

Here are my comments on the protocol draft.

These are long.  Many are editorial, but not all.

I have put in the page number for each piece of text I'm commenting on to help find the right text.  Quotes from the text are right shifted as they are in the doc, my comments are left justified and surrounded by
****
comment
****

--Sandy

IDnits reports 4 errors.
- There's no IANA considerations section, which is a required section.
- Two normative downrefs.
- No separation of references into normative vs informative.  (Fixing this might
fix the downrefs.)

"least recently added", "most recently added", "next most recently added",
"n order from most recently added to least recently added", "a current 
Secure_Path Segment that has the Confed_Segment flag set to zero, if the 
next most recently added Secure_Path segment" --
there must be a reason why you decided not to use a subscripted naming
scheme.  It may be just me, but I think subscripts work.

There are places where "should" is used, which do not seem to be "SHOULD".
But it would be good for one pass to make sure.

Purists say that SHOULD should (:-)) be accompanied by an explanation of
legitimate reasons why you might not.

Secure_Path Segment vs Secure_Path segment.  Similarly consistency in
underscores and hyphens (least-recently)  etc.  AS Number vs AS number.

Where do we put the discussion that a change in RPKI state should
cause re-run of the decision process?

I think somewhere we need an overarching statement that in receiving
updates that do not contain the bgpsec attribute and in propagating
those non-bgpsec updates, the implementation behaves exactly as is 
specified in 4271.

for a message with bgpsec attribute:
bgpsec speaker -> bgpsec speaker:  SHOULD add attribute, MAY remove block
                                   MAY remove attribute
bgpsec seaker -> non-bgpsec speaker: MUST remove bgpsec attribute, 
                                    MUST add AS_PATH

for a message with no bpgsec attribute (and therefore an AS_PATH):
bgpsec speaker --> bgpsec speaker : MUST NOT add bgpsec attribute
bgpsec speaker --> non-bgpsec speaker: MUST NOT add bgpsec attribute,
                                    MUST continue normal AS_PATH construction

page 3

   2.  Every AS listed in the AS_Path attribute of the update explicitly
       authorized the advertisement of the route to the subsequent AS in
       the AS_Path.

***
The AS_PATH is gone, so maybe you mean the list of ASs that appear in 
the bgpsec attribute
***

                                       Any BGPSEC speaker who wishes to
   send BGP update messages to external peers (eBGP) containing the
   BGPSEC_Path_Signatures must have an RPKI end-entity certificate (as
   well as the associated private signing key) corresponding to the
   BGPSEC speaker's AS number.  

***
wrt "must have"
There must exist such a EE cert, but the router may not need to have
possession on-box of that cert.  If the AS is using the same keys on
all routers, then maybe the router needs the common AS wide cert
(verifying signatures generated at confed boundaries, maybe?) but if
there are per-router keys then the router need not hold its own cert
on-box. I'd say the router definitely needs to have possession of its 
own private key (as long as you allow an off-box crypto engine as 
incorporated into the "router" by reference)
Right?
***

                               Note, however, that a BGPSEC speaker
   does not require such a certificate in order to validate update
   messages containing the BGPSEC_Path_Signatures attribute.

***
Kinda my point above.  Quibbling about the "such a cert" words - the
bgp speaker requires lots of such certificates to provide keys that 
validate signatures.  It does not validate signatures that it
has created itself, it is validating signatures created by other
bgp speakers.
***

Page 4

   If version 0 is the only version of BGPSEC for which both peers (in a
   BGP session) advertise support, then the use of BGPSEC has been
   negotiated and the BGPSEC peers MUST adhere to the specification of
   BGPSEC provided in this document.  (If there are multiple versions of
   BGPSEC which are supported by both peers, then the behavior of those
   peers is outside the scope of this document.)

***
Do we need to add "Any future specification of a version other than
0 MUST specify the behavior of bgp speakers who support multiple
versions and how they determine the version to use to communicate.
***

Page 5

   Note that if the BGPSEC speaker wishes to use BGPSEC with two
   different address families (i.e., IPv4 and IPv6) over the same BGP
   session, then the speaker must include two instances of this
   capability (one for each address family) in the BGP OPEN message.  A
   BGPSEC speaker SHOULD NOT advertise the capability of BGPSEC support
   for any <AFI, SAFI> combination unless it has also advertises the
                                                      ^^^^^^^^^^
                                                      advertised
   multiprotocol extension capability for the same <AFI, SAFI>
   combination [2].

   By indicating support for receiving BGPSEC update messages, a BGP
   speaker is, in particular, indicating that the following are true:

   o  The BGP speaker understands the BGPSEC_Path_Signatures attribute
      (see Section 3).

   o  The BGP speaker supports 4-byte AS numbers (see RFC 4893).

***
So what if the "Support for 4-octet AS number capability" capability 
is not also negotiated at the same time?  Then what?  Does negotiating
this capability mean you do not need to negotiate the 4byte capability?
***

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

***
So what if the extended msg capability is not negotiated at the same time?
Then what?  Etc.
***

   A BGP speaker MUST NOT send an update message containing the
   BGPSEC_Path_Signatures attribute within a given BGP session unless
   both of the following are true:

   o  The BGP speaker indicated support for sending BGPSEC update
      messages in its open message.

   o  The peer of the BGP speaker indicated support for receiving BGPSEC
      update messages in its open message.

***
If  both these statements are true, is sending a bgpsec attribute a
MUST? SHOULD? MAY?  [expect answer is SHOULD]
Maybe there needs to be a caveat about "only where this spec allows
addition of the bgpsec attribute".
***

Page 6

   The BGPSEC_Path_Signatures attribute is a new optional (non-
   transitive) BGP path attribute.

***
ibgp speakers will drop this if they are non-bgpsec-aware, which if I
have things correct means that route reflectors better be upgraded early
on.  The bgpsec ops doc says that.  Perhaps a ref to that doc?
if one edge router is not bgpsec aware, it might make inconsistent
decisions.  I think.  Is this a problem?  Or a reason why we should
be doing the validation-signalling draft?
***

   This document registers a new attribute type code for this attribute
   : TBD

   The BGPSEC_Path_Signatures algorithm carries the secured AS Path
   information, including the digital signatures that protect this AS
   Path information.  We refer to those update messages that contain the
   BGPSEC_Path_Signatures attribute as "BGPSEC Update messages".  The
   BGPSEC_Path_Signatures attribute replaces the AS_PATH attribute, in a
   BGPSEC update message.  That is, update messages that contain the
   BGPSEC_Path_Signatures attribute MUST NOT contain the AS_PATH
   attribute.

***
On a personal note, I like to think of the bgpsec attribute as
"encapsulating" the AS_PATH.  A quibble about terms, but "encapsulate"
for me captures the idea that it contains the same AS list as the AS_PATH
in another form, so loop checking still works, and AS_PATH length can
still be computed, etc.
***

Page 7

        High-Level Diagram of the BGPSEC_Path_Signatures Attribute
                          BGPSEC_Path_Signatures
        +---------------------------------------------------------+
        |     +-----------------+                                 |
        |     |   Secure Path   |        +-----------------+      |
        |     +-----------------+        | Additional Info |      |
        |     |    AS X         |        +-----------------+      |
        |     |    pCount X     |        |  Info Type      |      |
        |     |    Flags X      |        |  Info Length    |      |
        |     |    AS Y         |        |  Info Value     |      |
        |     |    pCount Y     |        +-----------------+      |
        |     |    Flags Y      |                                 |
        |     |      ...        |                                 |
        |     +-----------------+                                 |
        |                                                         |
        |     +-----------------+       +-----------------+       |
        |     | Sig Block 1     |       |  Sig Block 2    |       |
        |     +-----------------+       +-----------------+       |
        |     | Alg Suite 1     |       |  Alg Suite 2    |       |

***
The Signature_Block picture on page 11 says that there is a
Signature_Block Length field here
***

        |     | SKI X           |       |  SKI X          |       |
        |     | Sig Length X    |       |  Sig Length X   |       |
        |     | Signature X     |       |  Signature X    |       |
        |     | SKI Length Y    |       |  SKI Length Y   |       |

***
why is this SKI Length not included for X as well?
(figure this is an editing error)
***

        |     | SKI Y           |       |  SKI Y          |       |
        |     | Sig Length Y    |       |  Sig Length Y   |       |
        |     | Signature Y     |       |  Signature Y    |       |
        |     |      ...        |       |      ....       |       |
        |     +-----------------+       +-----------------+       |
        |                                                         |
        +---------------------------------------------------------+

Page 8

   be contained in the AS_PATH attribute.  A BGPSEC update message
   containing the BGPSEC_PATH_SIGNATURES attribute MUST NOT contain the
   AS_PATH attribute.  The path information is used by BGPSEC speakers
   in the same way that information from the AS_PATH is used by non-
   BGPSEC speakers.  The format of the Secure_Path is described below in
   Section 3.1.

***
"path information" meaning the list of ASs that appear in the list of
secure_path segments.  I think.  This needs to be more precise.
in cases where current bgp code refers to the AS_PATH (as in read
access), the code can refer to the as_path extracted from the bgpsec
signature attributes iaw section xyz.
in cases where current bgp speakers add ASs to the AS_PATH, the code
should be adding bgpsec signature attributes.
***

***
curiousity here: do current bgp implemenations ensure that you *ONLY*
add the local ASN on external sessions?
***
                                                        Note that this
   means the Secure_Path Length is six times the number Secure_Path
                                                       ^of
   Segments (i.e., the number of AS numbers in the path).

Page 9

***
Is it Secure_Path segment or Secure_Path Segment?  (case consistency)
****

Page 10

Page 11

   Here we provide a detailed description of the Signature_Blocks in the
                                                 ^^^^^^^^^^^^^^^^
                                                 Signature_Block

Page 12

                            Signature Segments
              +---------------------------------------------+
              | Subject Key Identifier        (20 octets)   |
              +---------------------------------------------+
              | Signature Length              (2 octets)    |
              +---------------------------------------------+
              | Signature                     (variable)    |
              +---------------------------------------------+

***
Page 7 has an SKI length, but as I said there I think that was a
remnant from editing.
***

4.  Generating a BGPSEC Update

***
I think somewhere we need an overarching statement that in receiving
updates that do not contain the bgpsec attribute and in propagating
those non-bgpsec updates, the implementation behaves exactly as is 
specified in 4271.
***
 
Page 13

   Note that in order to create or add a new signature to a BGPSEC
   update message with a given algorithm suite, the BGPSEC speaker must
   possess a private key suitable for generating signatures for this
   algorithm suite.  Additionally, this private key must correspond to
   the public key in a valid Resource PKI end-entity certificate whose
   AS number resource extension includes the BGPSEC speaker's AS number
   [11].  Note also that new signatures are only added to a BGPSEC
   update message when a BGPSEC speaker is generating an update message
   to send to an external peer (i.e., when the AS number of the peer is
   not equal to the BGPSEC speaker's own AS number).  

***
I think that this restriction has not been previously mentioned.  There
is previous text that talks about adding signatures when sending to an
external peer, but not the constraint that this is the *ONLY* case when
the bgpsec attribute is added

Note also.  In the AS aliasing case, the peer may be in the same AS in
some sense, but have a different ASN.  We will have to pay careful
attention to Wes/Shane's description of the aliasing case.
***

4.1.  Originating a New BGPSEC Update

***
See comment on page 17 about what happens when an internal bgpsec
speaker originates a route to a network.
***

   In an update message that originates a new route advertisement (i.e.,
   an update whose path will contain only a single AS number), when

***
path -> Secure Path
***

   First, the BGPSEC speaker constructs the Secure_Path with a single
   Secure_Path Segment.  The AS in this path is the BGPSEC speaker's own
   AS number.  In particular, this AS number MUST match the AS number in
   the AS number resource extension field of the Resource PKI end-entity
   certificate(s) that will be used to verify the digital signature(s)
   constructed by this BGPSEC speaker.

***
"will be used" - this is not a action constraint on the protocol, but more
an operational or configuration problem.  That is, how does the sender know
what the recipient will use?  A: by putting the AS in the field.  That's
circular.  This should be a note to operators - make sure there's a RPKI
cert for the AS you are configuring for the implementation
***

Page 14

   If the BGPSEC speaker is not a member of an autonomous system
   confederation [3], then the Flags field of the Secure_Path Segment
   MUST be set to zero.  (Members of a confederation should follow the
   special processing instructions for confederation members in Section
   4.4.)

***
It is not just that the speaker is in some confederation.  I think the 
flag is set to 1 if you and your neighbor are in the same confederation.  
I don't think this text says that.  I think phrasing it as "when speaker
and neighbor are in same confed, then 1, else 0" might be easier phrasing.
***

   The BGPSEC speaker next constructs the Additional_Info portion of the
   BGPSEC_Path_Signatures attribute.  The Info Type MUST be set to zero
   and the Info Length MUST also be set to zero.  The Info Value field
   is empty (has length zero).  It is anticipated that future
   specifications may specify values of Info Type other than zero.
   Therefore, BGPSEC receivers compliant with this specification must be
   able to accept Additional_Info fields with non-zero Info Type.  Such
   receivers will use the Additional_Field to verify digital signatures
   (see Section 5) but will otherwise ignore Additional_Field non-zero
   Info Fields.

***
Is it OK if people use the A.I. field to trnasmit info to people who
know what to do with it?  (we just created a covert channel? can't come up
with a reason why that is bad, just curious.)
***

Page 15

   The Subject Key Identifier field (see Section 3) is populated with
   the identifier contained in the Subject Key Identifier extension of
   the RPKI end-entity certificate used by the BGPSEC speaker.  This
   Subject Key Identifier will be used by recipients of the route
   advertisement to identify the proper certificate to use in verifying
   the signature.

***
I don't think that "used by the BGPSEC speaker" is quite right.  You mean
something like "corresponding to" or something vague like that.
***

Page 16

   If a BGPSEC router has received only non-BGPSEC update messages
   (without the BGPSEC_Path_Signatures attribute), containing the
   AS_Path attribute, from a peer for a given prefix and if it chooses
   to propagate that peer's route for the prefix, then it MUST NOT
   attach any BGPSEC_Path_Signatures attribute to the corresponding
   update being propagated.  

***
I think this is the case whenever the path you choose to propagate
has no bgpsec attribute, whether or not *all* the paths you have received
have no bgpsec attribute.  I think this is just a wording issue, but
people should be sure.  Verify: we DO NOT mandate that you choose and 
propagate a non-bgpsec message only if you have received NO bgpsec messages.
***
                           (Note that a BGPSEC router may also receive

Page 17

   a non-BGPSEC update message from an internal peer without the AS_Path
   attribute, i.e., with just the NLRI in it.  In that case, the prefix
   is originating from that AS and hence the BGPSEC speaker SHOULD sign
   and forward the update to its external peers, as specified in Section
   4.1.)

***
First: the AS_PATH is empty, not missing.

Second, when an edge router receives a route from an internal peer when
the nlri is originated internally, the update will contain an as-path that
is empty if the internal originator is a non-bgpsec speaker.  Yep.
What if the originator is a bgpsec speaker?  What does an internal
originator do when originating a route?  no bgpsec attribute at all?
an empty bgpsec attribute?  Empty attribute emulates the behavior
in the as_path case but the as_path is mandatory so they have to
include it.  No bgpsec attribute follows the rule that the attribute
is not added over internal sessions, is only added on the edge.  But
means lots of special cases for the as_path extraction and tools that
need to know that no attribute and no as_path means a bgpsec message.
Etc.
***

   Conversely, if a BGPSEC router has received a BGPSEC update message
   (with the BGPSEC_Path_Signatures attribute) from a peer for a given
   prefix and it chooses to propagate that peer's route for the prefix,
   then it SHOULD propagate the route as a BGPSEC update message
   containing the BGPSEC_Path_Signatures attribute.  

***
propagate to all neighbors who have negotiated the bgpsec attribute
***
                                                    However, the BGPSEC
   speaker MAY propagate the route as a (unsigned) BGP update message
   without the BGPSEC_Path_Signatures attribute.

   Note that removing BGPSEC signatures (i.e., propagating a route
   advertisement without the BGPSEC_Path_Signatures attribute) has
   significant security ramifications.  (See Section 7 for discussion of
   the security ramifications of removing BGPSEC signatures.)
   Therefore, when a route advertisement is received via a BGPSEC update
   message, propagating the route advertisement without the
   BGPSEC_Path_Signatures attribute is NOT RECOMMENDED.  

***
propagating to a neighbor how has neogiated the bgpsec attribut
***

   To generate the BGPSEC_Path_Signatures attribute on the outgoing
   update message, the BGPSEC speaker first prepends a new Secure_Path
   Segment (places in first position) to the Secure_Path.  The AS number
   in this Secure_Path segment MUST match the AS number in the AS number
   resource extension field of the Resource PKI end-entity
   certificate(s) that will be used to verify the digital signature(s)
   constructed by this BGPSEC speaker.

***
Again, this is an operational comment, not a protocol behavior.  There
must exist a cert corresponding to the private key 
***

   The pCount is typically set to the value 1.  A BGPSEC speaker may set
   the pCount field to a value greater than 1.  (See Section 4.1 for a
   discussion of setting pCount to a value greater than 1.)  A route
   server that participates in the BGP control path, but does not act as

Page 18

   a transit AS in the data plane, may choose to set pCount to 0.  This
   option enables the route server to participate in BGPSEC and obtain
   the associated security guarantees without increasing the effective
   length of the AS path.  

***
We are now considering the use of pcount=0 to allow for as aliasing.
We don't know yet if that will be effective (see Wes George's recent
draft).  But who knows there might be others.  It might be good to say
There might be operational need that would be met by employing a
pcount value of 0.  One example is route servers.
***
                          (Note that BGPSEC speakers compute the
   effective length of the AS path by summing the pCount values in the
   BGPSEC_Path_Signatures attribute, see Section 5.)  However, when a
   route server sets the pCount value to 0, it still inserts its AS
   number into the Secure_Path segment, as this information is needed to
   validate the signature added by the route server.  Note that the
   option of setting pCount to 0 is intended only for use by route
   servers that desire not to increase the effective AS-PATH length of
   routes they advertise.  The pCount field SHOULD NOT be set to 0 in
   other circumstances.  

***
as aliasing is a possible other use.  whether or not that works out,
putting this statement here seems inadvisable.
***

                         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 (i.e., cases where the
   peer is not acting as a route server).

***
Again, we might not end up limiting the use to route servers, so...
***

Page 19

   corresponding Signature_Block) that is deemed 'Good'.  This means
   that a 'Good' BGPSEC update message may contain a Signature_Block
   which is not deemed 'Good' (e.g., contains signatures that the BGPSEC
   does not successfully verify).  Nonetheless, such Signature_Blocks
   MUST NOT be removed.  (See Section 7 for a discussion of the security
   ramifications of this design choice.)

***
There is only a SHOULD NOT for removing the signatures in total when they
invalidate.  So why this MUST NOT for when just one algorithm fails?  Is
it a worse security concern?
***

Page 20

                      Sequence of Octets to be Signed
       +--------------------------------------+
       | Target AS Number        (4 octets)   |
       +--------------------------------------+
       | Signer's AS Number      (4 octets)   |  ---\
       +--------------------------------------+      \
       | pCount                  (1 octet)    |       >  Secure_Path
       +--------- ----------------------------+      /
       | Flags                   (1 octet)    |  ---/
       +--------------------------------------+
       | Most Recent Sig Field   (variable)   |
       +--------------------------------------+

***
This is a Secure_Path *Segment*, I think.
***

   Within a confederation, the verification of BGPSEC signatures added
   by other members of the confederation is optional.  If a

***
Isn't verification always optional?
***

Page 21

   message to a peer that is a member of the same confederation, the
   confederation MAY set the Signature field within the
   Signature_Segment that it generates to be zero (in lieu of
   calculating the correct digital signature as described in Sections
   4.1 and 4.2).  Note that if a confederation chooses not to verify
   digital signatures within the confederation, then BGPSEC is able to
   provide no assurances about the integrity of the (private) Member-AS
   Numbers placed in Secure_Path segments where the Confed_Segment flag
   is set to one.

***
Should there be a security considerations discussion of this?
***

   When a confederation member receives a BGPSEC update message from a
   peer within the confederation and propagates it to a peer outside the
   confederation, it must remove all of the Secure_Path Segments added
   by confederation members as well as the corresponding Signature
   Segments.  To do this, the confederation member propagating the route
   outside the confederation does the following:

   o  First, starting with the least recently added Secure_Path
      segments, remove all of the consecutive Secure_Path segments that
      have the Confed_Segment flag set to one.  Stop this process once a
      Scure_Path segment is reached which has its Confed_Segment flag
      set to zero.  Keep a count of the number of segments removed in
      this fashion.

***
Why does this start with the least recently added segment?  Isn't that
the origin segment?  (Oh, for an indexed name!)
***

   o  Second, starting with the most recently added Signature Segment,
      remove a number of Signature Segments equal to the number of
      Secure_Path Segments removed in the previous step.  (That is,
      remove the K most recently added signature segments, where K is
      the number of Secure_Path Segments removed in the previous step.)

***
Why two passes through the bgpsec attribute?  Why not a loop that looks at
the secure_path segment list and signature_block segment list in lock step?
And break the loop when you hit flag(i)=0?  They are completely synchronous
aren't they?
*** 
   o  Finally, add a Secure_Path Segment containing, in the AS field,
      the AS Confederation Identifier (the public AS number of the
      confederation) as well as a corresponding Signature Segment.  Note
      that all fields other that the AS field are populated as per
      Sections 4.1 and 4.2.

   When validating a received BGPSEC update message, confederation
   members must make the following adjustment to the algorithm presented
   in Section 5.2.  When a confederation member processes (validates) a
   Signature Segment and its corresponding Secure_Path Segment, the
   confederation member must note that for a signature produced by a
   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.

***
This should be mentioned in the validation section.  As well as here
or instead of here.  (both places or only there)
***

   To handle this case, when a BGPSEC speaker (that is a confederation
   member) processes a current Secure_Path Segment that has the
   Confed_Segment flag set to zero, if the next most recently added

Page 22

   Secure_Path segment has the Confed_Segment flag set to one then, when
   computing the digest for the current Secure_Path segment, the BGPSEC
   speaker takes the Target AS Number to be the AS Confederation
   Identifier of the validating BGPSEC speaker's own confederation.
   (Note that the algorithm in Section 5.2 processes Secure_Path
   Segments in order from most recently added to least recently added,
   therefore this special case will apply to the first Secure_Path
   segment that the algorithm encounters that has the Confed_Segment
   flag set to one.)

***
Don't you mean "flag set to zero" in that last line?
I can't claim to have followed the order here, so I could be wrong.
***

                                               (Such an error is treated
   in exactly the same way as receipt of a non-BGPSEC update message
   containing an AS_CONFED_SEQUENCE from a peer that is not a member of
   the same AS confederation.)

***
See section 5 of rfc 5064, but that refers to 4271 section 6.3.
That would send a Notification that breaks the session.  Not what
we want, I think.
And there's a work going on in idr right now that is reviewing the
whole subject of how bgp does error handling.
But we do want to modify the behavior of 6.3, which mandates
an error if a mandatory attribute is not present (like, oh, AS_PATH).
***

Page 23

5.  Processing a Received BGPSEC Update

   Upon receiving a BGPSEC update message from an external (eBGP) peer,
   a BGPSEC speaker SHOULD validate the message to determine the
   authenticity of the AS PATH information contained in the

Page 24

   BGPSEC_Path_Signatures attribute.  Section 5.1 provides an overview
   of BGPSEC validation and Section 5.2 provides a specific algorithm
   for performing such validation.  (Note that an implementation need
   not follow the specific algorithm in Section 5.2 as long as the input
   output behavior of the validation is identical to that of the

***
input output -> "input and output"?  "input/output"?
***
 
   BGPSEC_Path_Signatures attribute.  Whenever the use of AS path
   information is called for (e.g., loop detection, or use of AS path
   length in best path selection) the externally visible behavior of the
                                 ^,
   implementation shall be the same as if the implementation had run the
   algorithm in Section 4.4 and used the resulting AS_PATH attribute as
   it would for a non-BGPSEC update message.  However, in practice, it
   is expected that most implementations will not actually run the
   algorithm from Section 4.4, and will instead transform the
   BGPSEC_Path_Signatures attribute directly into some internal
   representation of AS path.

***
I'm not sure the "However" sentence is necessary.  We do intend for
the implementation to follow 4.4, whether they end up with an actual
AS_PATH attribute or some internal representation of the same, right?
Or maybe you are trying to distinguish running the 4.4 algorithm for
each use vs run once and store the result?
Aren't implementers already accustomed to using their
internal representation for any structure mentioned in a specification?
***

 Page 25

   between two update messages then the two updates are not duplicates.

   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).  If the
   first update message is not valid, then an implementation SHOULD run
   the validation procedure on the second duplicate update message (as
   the signatures in the second update may be valid even though the
   first contained a signature that was invalid).

***
Why is the converse not also true?  Could RPKI state change not just as
well make the second validation result differ from the first -- the first
update signature looked valid but now the signature looks invalid?
***

5.1.  Overview of BGPSEC Validation

   Validation of a BGPSEC update messages makes use of data from RPKI
   certificates and signed Route Origination Authorizations (ROA).  In
   particular, to validate update messages containing the
   BGPSEC_Path_Signatures attribute, it is necessary that the recipient
   have access to the following data obtained from valid RPKI
   certificates and ROAs:

   o  For each valid RPKI end-entity certificate containing an AS Number
      extension, the AS Number, Public Key and Subject Key Identifier
      are required,

***
"containing an AS number extension" -> that's a way to refer to router 
certs, right?  Perhaps we can name them?
Needs a reference to the router certs I-D.
***

   policy mechanisms.  It is expected that BGP peers will generally
   prefer routes received via 'Good' BGPSEC update messages over routes
   received via 'Not Good' BGPSEC update messages as well as routes
   received via update messages that do not contain the
   BGPSEC_Path_Signatures attribute.  However, BGPSEC specifies no

***
The "as well as" confuses me.
I think you mean "prefer ... Good ... over ... Not Good ... and over
... non-bgpsec".
But I had to think about that.
***

Page 26

   changes to the BGP decision process and leaves to the operator the
   selection of an appropriate policy mechanism to achieve the
   operator's desired results within the BGP decision process.

   BGPSEC validation needs only be performed at eBGP edge.  The
                     ^need only be?  (admit I'm not sure)
   validation status of a BGP signed/unsigned update MAY be conveyed via
                              bgpsec/non-bgpsec
   iBGP from an ingress edge router to an egress edge router.  Local
   policy in the AS determines the specific means for conveying the
   validation status through various pre-existing mechanisms (e.g.,
   modifying an attribute).  As discussed in Section 4, when a BGPSEC

***
did you mean "community" rather than "attribute"?  isn't every mechanism
modifying some attribute?
***

5.2.  Validation Algorithm

Some of this looks like syntax checking, not really validation.  Do the
syntac checks need to be separated, or is all one task?

Page 27

   Signature_Block.  If the BGPSEC_Path_Signatures attribute contains an
   error that is not local to one of two Signature_Blocks, then the
                                    ^the
   recipient should log that an error occurred and drop the update
   message containing the error.  (In particular, if any of checks 3-5
   above fail, the recipient should log that an error occurred and drop
   the update message containing the error.)

***
Is it not the case that if 1 or 2 fail, the error should be logged and 
the update dropped?  If so, why this comment?  If not, why not?
***

   Next, the BGPSEC speaker verifies that the origin AS is authorized to
   advertise the prefix in question.  To do this, consult the valid ROA
   data to obtain a list of AS numbers that are associated with the
   given IP address prefix in the update message.  Then locate the last
   (least recently added) AS number in the Secure_Path portion of the
   BGPSEC_Path_Signatures attribute.  If the origin AS in the
   Secure_Path is not in the set of AS numbers associated with the given
   prefix, then the BGPSEC update message is 'Not Good' and the
   validation algorithm terminates.

***
To answer those who are confused by the origin validation having three
states and bgpsec having two, should a note be put here that bgpsec
messages will only allow origins that are "Valid" and not origins that
are "Unkown"?  So in bgpsec, the "unknown" origins get lumped in with
the "invalid" origins into the "Not Good" category?
***

   Finally, the BGPSEC speaker examines the Signature_Blocks in the
   BGPSEC_Path_Signatures attribute.  A Signature_Block corresponding to
   an algorithm suite that the BGPSEC speaker does not support is not
   considered in validation.  If there does not exist a Signature_Block
   corresponding to an algorithm suite that the BGPSEC speaker supports,
   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_Signatures attribute.

***
I thought that sig blocks for unrecognized sig algs were dropped, not
just ignored in validation.
***

Page 28

                      Sequence of Octets to be Hashed

     +-------------------------------------------+
     | AS Number of Target AS         (4 octets) |
     +-------------------------------------------+
     | AS Number                      (4 octets) |  ---\
     +-------------------------------------------+      \
     | pCount                         (1 octet)  |       >  Secure_Path
     +-------------------------------------------+      /
     | Flags                          (1 octet)  |  ---/
     +-------------------------------------------+
     | Sig Field in the Next Segment  (variable) |
     +-------------- ----------------------------+

***
Think this is supposed to be Secure_Path Segment
This happens other places as well, I'm not going to note it everywhere
***

Page 29

Page 30

      signature is invalid, then mark the entire Signature-List Block as
      'Not Good' and proceed to the next Signature_Block.  If the
      signature validation algorithm determines that the signature is
      valid, then continue processing Signature-Segments (within the
      current Signature-List Block).

   If all Signature-Segments within a Signature-List Block pass
   validation (i.e., all segments are processed and the Signature-List
   Block has not yet been marked 'Not Good'), then the Signature_Block
   is marked as 'Good'.

   If at least one Signature_Block is marked as 'Good', then the
   validation algorithm terminates and the BGPSEC update message is
   deemed to be 'Good'.  (That is, if a BGPSEC update message contains
   two Signature_Blocks then the update message is deemed 'Good' if the
   first Signature_Block is marked 'Good' OR the second Signature_Block
   is marked 'Good'.)

***
So if one is good, is there any reason to try to the other?  you would
propagage it even if it were not, and by this point you know it is
syntactically valid, right?
****

6.  Algorithms and Extensibility

6.1.  Algorithm Suite Considerations

***
How much of this section is needed and how much can just refer to the
algorithm agility draft?
***

   complete, use of the old 'current' algorithm will be deprecated, use
   of the 'new' algorithm will be mandatory, and a subsequent 'even

Page 31

   newer' algorithm suite may be specified as recommend to implement.

***
I do not believe that once algorithm transition has completed that there
will necessarily be a "even newer" algorithm proposed.
***

   Once the transition has successfully been completed in this manner,
   BGPSEC speakers SHOULD include only a single Signature_Block
   (corresponding to the 'new' algorithm).

***
What is the signal to revert to just sending on sig block?  The end of
life deadline in the alg agility draft?

I believe that alg agility draft allows for router certs to be of mixed
algorithm.  That might affect the timeline.
***

   In the case that such a change to BGPSEC were deemed desirable, it is
   expected that a subsequent version of BGPSEC would be created and
   that this version of BGPSEC would specify a new BGP Path Attribute,

***
If BGP Path Attribute means the attribute defined here, you should call
it by the name used here.
***

   let's call it BGPSEC_PATH_SIG_TWO, which is designed to accommodate
   the desired changes to BGPSEC.  In such a case, the mandatory
   algorithm suites document would be updated to specify algorithm
   suites appropriate for the new version of BGPSEC.

***
Any such new version of BGP would also have to produce a new version of
this draft to talk about generating and validating the new attribute.
***

Page 32

   path.)  Furthermore, the recipient is assured that this path
   terminates in an autonomous system that has been authorized by the IP
   address space holder as a legitimate destination for traffic to the
   given prefix.

***
I'd say that the legitimate destination is the prefix, not the AS that
is originating a route to the prefix.

I think the path terminates in an AS that has a direct connection to the
prefix.  That is probably subject to the caveats that seem to always show
up.  (We've disallowed AS_SETs, so that caveat does not apply).  Hm.
Terminates in an AS that can deliver traffic to the prefix without the
assistance of any other publically announced AS (ie it could go through
private ASs to get there.)
***

   Note that although BGPSEC provides a mechanism for an AS to validate
   that a received update message has certain security properties, the
   use of such a mechanism to influence route selection is completely a
   matter of local policy.  Therefore, a BGPSEC speaker can make no
   assumptions about the validity of a route received from an external
   BGPSEC peer.  That is, a compliant BGPSEC peer may (depending on the
   local policy of the peer) send update messages that fail the validity
   test in Section 5.  Thus, a BGPSEC speaker MUST completely validate
   all BGPSEC update messages received from external peers.  (Validation
   of update messages received from internal peers is a matter of local
   policy, see Section 5).

***
What does MUST completely validate mean? what is a not completely 
validated message?
And why is this a MUST? Since we allow propagation of messages that 
are Not Good, this seems an odd requirement.
***

Page 33

   To understand the reason for such a design decision consider the case
   where the BGPSEC speaker receives an update message with both a set
   of algorithm A signatures which are 'Good' and a set of algorithm B
   signatures which are 'Not Good'.  In such a case it is possible
   (perhaps even quite likely) that some of the BGPSEC speaker's peers
   (or other entities further 'downstream' in the BGP topology) do not
   support algorithm A. Therefore, if the BGPSEC speaker were to remove
   the 'Not Good' set of signatures corresponding to algorithm B, such
   entities would treat the message as though it were unsigned.  By
   including the 'Not Good' set of signatures when propagating a route
   advertisement, the BGPSEC speaker ensures that 'downstream' entities
   have as much information as possible to make an informed opinion
   about the validation status of a BGPSEC update.

   Note also that during a period of partial BGPSEC deployment, a
   'downstream' entity might reasonably treat unsigned messages
   different from BGPSEC updates that contain a single set of 'Not Good'
   ^differently

***
actually, it is more than they might be treated differently, it is that
unsigned might be preferred over Not Good.
***

   signatures.  That is, by removing the set of 'Not Good' signatures
   the BGPSEC speaker might actually cause a downstream entity to
   'upgrade' the status of a route advertisement from 'Not Good' to
   unsigned.  Finally, note that in the above scenario, the BGPSEC
   speaker might have deemed algorithm A signatures 'Good' only because
   of some issue with RPKI state local to his AS (for example, his AS
   might not yet have obtained a CRL indicating that a key used to
   verify an algorithm A signature belongs to a newly revoked
   certificate).  In such a case, it is highly desirable for a
   downstream entity to treat the update as 'Not Good' (due to the
   revocation) and not as 'unsigned' (which would happen if the 'Not
   Good' Signature_Blocks were removed).

Page 34

   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 effective 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 effective 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 in which an upstream entity that
   is two or more hops away set pCount to zero is unable to verify for
   themselves whether pCount was set to zero legitimately.

***
As there are suggestions of using pcount=0 for the AS aliasing work,
we might not want to be specific about the use case here.
The recipient should check to be sure that pcount=0 only when it expects
that peer to be using pcount=0.  We can't force the reasoning behind
the configuration anyway.
*** 

   EDITOR'S NOTE: Do we want to mandate a specific transport security
   mechanism (e.g., TCP-AO)?

***
If we do, then implementers would be required to use that transport for
compliance - last I heard the TCP-AO implementations were not there yet.
Tho' it will be a long while before this implementation is there yet either,
so it may not matter.
***

Page 35

   Randy Bush begin_of_the_skype_highlighting     end_of_the_skype_highlighting
   Internet Initiative Japan
   [email-masked]

***
figure this is a cut and paste error
***