Re: [sidr] WGLC for draft-ietf-sidr-bgpsec-protocol-05

[Randy Bush <[e-mail]>]

my apologies for the bald and boring ascii text.  if you wish i can put
it in word perfect or pdf.  :)
</in joke>

the document seems to have lost that Router Certificates for key sets
may be per router, not just per AS.  see section 3.1.1.1 (sic), Subject,
of draft-ietf-sidr-bgpsec-pki-profiles.  as an AS may have hundreds of
BGPSEC speaking edge routers, you don't want to have to search the whole
bag of Router Certificates for an AS to find the cert/key that verifies
a particular signature.  and you can not just use the router-id of the
peer AS received in the bgp open, as you will also need the router-ids
of the signers further down the path.

the document repeaytedly refers to EE Certs etc. where it should simply
reference BGPsec Router Certificates as described in Section 3.1 of
[I-D.ietf-sidr-bgpsec-pki-profiles]

in general, i think the wording is redundant and unnecessarily complex
in many places.  but that is probably as much my disease than the editor's.

---

Abstract

   This document describes BGPSEC, an extension to the Border Gateway
   Protocol (BGP) that provides security for the AS-PATH attribute in
   BGP update messages.

uh, the bgp attribute is AS_PATH, note the underbar

and since it removes the AS_PATH attribute, it does not really secure
it.

in general, i think the nomenclature needs tightening, and it needs a
clear phrase for the ASs through which the announcement has been routed.

--

Requirements Language

fwiw, recently i have been using more specific language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
   be interpreted as described in RFC 2119 [RFC2119] only when they
   appear in all upper case.  They may also appear in lower or mixed
   case as English words, without normative meaning.

--

1.  Introduction

   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.

ain't no as_path attribute in a bgpsec update.  it seems to be the
bgpsec_path_signatures attribute.  btw, why not just bgpsec_path?
or more formally BGPSEC_PATH

--

   This document specifies a new optional (non-transitive) BGP path

why is "non-transitive" in parens?

--

   the documents referenced therein.)  Any BGPSEC speaker who wishes to
   send BGP update messages to external peers (eBGP) containing the
   BGPSEC_Path_Signatures

scrambled.  the external peers do not contain 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.

i think you want to refer to BGPsec Router Certificates as described in
Section 3.1 of [I-D.ietf-sidr-bgpsec-pki-profiles]

--

2.  BGPSEC Negotiation

   This document defines a new BGP capability [4]that allows a BGP
   speaker to advertise to its neighbors the ability to send and/or

it advertises to *a* neighbor

--

                    0        1        2  3       4 5 6 7
                 +---------------------------------------+
                 | Send | Receive | Reserved  |  Version |
                 +---------------------------------------+
                 |               AFI                     |
                 +---------------------------------------+
                 |                                       |
                 +---------------------------------------+
                 |             Reserved                  |
                 +---------------------------------------+
                 |               SAFI                    |
                 +---------------------------------------+

remove the middle part of the line between AFI and the following octet.
e.g.

                 +---------------------------------------+
                 |                                       |
                 +----             AFI           --------+
                 |                                       |
                 +---------------------------------------+

--


   The high order bit (bit 0) of the first octet is set to 1 to indicate
   that the sender is able to send BGPSEC update messages, and is set to
   zero otherwise.  The next highest order bit (bit 1) of this octet is
   set to 1 to indicate that the sender is able to receive BGPSEC update
   messages, and is set to zero otherwise.

this leaves open that both may be zero

--

   The BGPSEC_Path_Signatures algorithm carries the secured AS Path
   information, including the digital signatures that protect this AS

"algorithm?"  attribute, i suspect

--

   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.

and vice versa

--

                     BGPSEC_Path_Signatures Attribute

         +-------------------------------------------------------+
         | Secure_Path                             (variable)    |
         +-------------------------------------------------------+
         | Additional_Info                         (variable)    |
         +-------------------------------------------------------+
         | Sequence of one or two Signature_Blocks (variable)    |
         +-------------------------------------------------------+


   The Secure_Path contains AS Path information for the BGPSEC update

"Path" should probably be lower case to avoid confusion

--

   message.  This is logically equivalent to the information that would
   be contained in the AS_PATH attribute.

s/would be contained in the/is contained in a non-BGPSEC/

--

                       The path information is used by BGPSEC speakers
   in the same way that information from the AS_PATH is used by non-
   BGPSEC speakers.

s/path information/Secure_Path/

--

   suite.  Each of the Signature_Blocks will contain a signature segment
   for each AS number (i.e, secure path segment) in the Secure_Path.

s/each/one/

--

                                       However, in order to enable a
   transition from an old algorithm suite to a new algorithm suite

without a flag day

--

   The Secure_Path Length contains the length (in octets) of the
   variable-length sequence of Secure_Path Segments.  As explained
   below, each Secure_Path segment is six octets long.  Note that this
   means the Secure_Path Length is six times the number Secure_Path
   Segments (i.e., the number of AS numbers in the path).

imiho, L in TLV includes itself so that you can just skip over that many
octets.  i.e. it would be 2 x segments + 2.  this occurs throughout.

--

   The Secure_Path contains one Secure_Path segment for each (distinct)

capitalize Segment

--

   Autonomous System in the path to the NLRI specified in the update
   message.

in the path to the origiating AS of the NLRI

--

                            Secure_Path Segment

                       +----------------------------+
                       | AS Number      (4 octets)  |
                       +----------------------------+
                       | pCount         (1 octet)   |
                       +----------------------------+
                       | Flags          (1 octet)   |
                       +----------------------------+

you are going to need the Router-ID of the signing router so that the
verifier knows which BGPsec Router Certificate to choose.

--

   The pCount field contains the number of repetitions of the associated
   autonomous system number that the signature covers.  This field
   enables a BGPSEC speaker to mimic the semantics of adding multiple

s/adding/prepending/

--

   The remaining seven bits of the Flags field are reserved for future
   use.  These bits MUST be set to zero by the sender.  The receiver
   uses the entire Flags octet to verify the digital signature
   (regardless of what value the reserved bits contain)

The remaining seven bits of the Flags MUST be set to zero by the sender,
and the signature is computed over all seven bits of the Flags.

--

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


   The Subject Key Identifier contains the value in the Subject Key
   Identifier extension of the RPKI end-entity certificate 

again. please refer to BGPsec Router Certificates as described in
Section 3.1 of [I-D.ietf-sidr-bgpsec-pki-profiles]

--

4.  Generating a BGPSEC Update

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

you do not mention that it could be a per-router-id key set.

--

4.1.  Originating a New BGPSEC Update

   The pCount field of the Secure_Path Segment is typically set to the
   value 1.  However, a BGPSEC speaker may set the pCount field to a
   value greater than 1.  Setting the pCount field to a value greater
   than one has the same semantics as repeating an AS number multiple
   times in the AS_PATH of a non-BGPSEC update message (e.g., for
   traffic engineering purposes).  Setting the pCount field to a value
   greater than one permits this repetition without requiring a separate
   digital signature for each repetition.

it may be zero in certain special circumstances, see section 42.666

--

   o  Construct a sequence of octets by concatenating the Target AS
      Number, the Secure_Path (Origin AS, pCount, and Flags), the
                                         ^ Router-ID

--

4.2.  Propagating a Route Advertisement

   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 

s/messages/message/

--

   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.

unless the peer to which the BGPSEC speaker is sending did not signal
the ability to receive BGPSEC in the capability negotiation.  if this is
the case, see section 42.666 for converting to AS_PATH.

--

   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.

it might be prudent to not talk about the whole flags field, as we do
not know what exciting future may lie before it.  just talk about the 
Confed_Segment flag.

--

   If the received BGPSEC update message contains two Signature_ Blocks
   and the BGPSEC speaker supports both of the corresponding algorithms
   suites, then the new update message generated by the BGPSEC speaker
   SHOULD include both of the Signature_Blocks.  If the received BGPSEC
   update message contains two Signature_Blocks and the BGPSEC speaker
   only supports one of the two corresponding algorithm suites, then the
   BGPSEC speaker MUST remove the Signature_Block corresponding to the
   algorithm suite that it does not understand.  If the BGPSEC speaker
   does not support the algorithm suites in any of the Signature_Blocks
   contained in the received update message, then the BGPSEC speaker
   MUST NOT propagate the route advertisement with the
   BGPSEC_Path_Signatures attribute (i.e., propagate it as an unsigned
   BGP update message).

explain why.  the speaker can not add its info to a sig block for which
it does not understand the alg.  and there can not be a gap in the sig
block.

--

4.3.  Processing Instructions for Confederation Members

   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.

s/least/most/

--

4.4.  Reconstructing the AS_PATH Attribute

   2.  If the Confed_Segment flag in the Secure_Path segment is set to
       zero, then look at the most-recently added segment in the
       AS_PATH.

       *  In the case where the AS_PATH is empty then add (prepend to
          the AS_PATH) a new AS_PATH segment of type AS_SEQUENCE.

In the case where the AS_PATH is empty and pcount is greater than zero,
...

--

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

AS PATH is confusing.  maybe

   Upon receiving a BGPSEC update message from an external (eBGP) peer,
   a BGPSEC speaker SHOULD validate the message to determine the
   authenticity of the data covered by the BGPSEC_Path_Signatures
   attribute.

--

                                          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.

how about just saying that it will behave the same, and do not say it
actually has to transform it in any way?

--

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

in the very next section, you use the words "Good" and "Not Good."
there is a consistency problem, and not just here.

--

  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,

and router-id

--

   o  For each valid ROA, the AS Number and the list of IP address
      prefixes.

what is a 'valid' roa?

--

   Note that the BGPSEC speaker could perform the validation of RPKI
   certificates and ROAs on its own and extract the required data, or it
   could receive the same data from a trusted cache that performs RPKI
   validation on behalf of (some set of) BGPSEC speakers.  (The latter
   case in analogous to the use of the RPKI-RTR protocol [13] for origin
   validation.)

draft-ymbk-rpki-rtr-keys is soon to describe a new rpki-rtr pdu to
handle the per-as and per-router keys

--

   It is expected that the output of the validation procedure will be
   used as an input to BGP route selection.  However, BGP route
   selection and thus the handling of the two validation states is a
   matter of local policy, and shall be handled using existing local
   policy mechanisms.

s/existing// i.e. a vendor could create a new testable attribute
bgpsec-state.

--

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

someone should write a draft something like draft-ietf-sidr-bgpsec-ops

--

   BGPSEC validation needs only be performed at eBGP edge.  The
   validation status of a BGP signed/unsigned update MAY be conveyed via
   iBGP from an ingress edge router to an egress edge router.

how?  where are the bits to carry validation state?

--

   Local
   policy in the AS determines the specific means for conveying the
   validation status through various pre-existing mechanisms (e.g.,
   modifying an attribute).

imiho, this document should not get into all the lovely things local
policy might do unless it is required for bgpsec, and nothing should
be in that set.

--

   As discussed in Section 4, when a BGPSEC
   speaker chooses to forward a (syntactically correct) BGPSEC update
   message, it SHOULD be forwarded with its BGPSEC_Path_Signatures
   attribute intact (regardless of the validation state of the update
   message).

no.  not when the speaker does not understand one of the algorithms.

--

   Based entirely on local policy settings, an egress router
   MAY trust the validation status conveyed by an ingress router or it
   MAY perform its own validation.

or it can just sign it and not test anything at all.  this does not need
to be said

--

5.2.  Validation Algorithm

   3.  Check that the update message does not contain both a
       BGPSEC_Path_Signatures attribute and an AS_PATH attribute.

this sentence implies bgpsec validation could happen on an update with
only as_path.  you want to simply say no as_path is allowed.

--

   If there are two Signature_Blocks within the BGPSEC_Path_Signatures
   attribute and one of them is poorly formed (or contains the wrong
   number of Signature segments) , then the recipient should log that an
   error occurred

s/log/inform the operator/  i.e. it could snmp trap etc

--

   strip off that particular Signature_Block and process
   the update message as though it arrived with a single
   Signature_Block.  If the BGPSEC_Path_Signatures attribute contains an
   error that is not local to one of two Signature_Blocks, then the
   recipient should log that an error occurred

s/log/inform the operator/

--

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

s/log/inform the operator/

--

   o  (Step II): Compute the digest function (for the given algorithm
      suite) on the appropriate data.  If the segment is not the (least
      recently added) segment corresponding to the origin AS, then the
      digest function should be computed on the following sequence of
      octets:

                      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) |
     +-------------- ----------------------------+
                    ^
did the router-id fall through that little hole? :)

--

7.  Security Considerations

   o  The origin AS number corresponds to an autonomous system that has
      been authorized by the IP address space holder to originate route
                     ^ in the RPKI
      advertisements for the given prefix.

   o  For each AS number in the AS Path, a BGPSEC speaker authorized by
                                                        in the RPKI ^
      the holder of the AS number intentionally chose (in accordance
      with local policy) to propagate the route advertisement to the
      next AS in the Secure_Path.

--

   That is, the recipient of a valid BGPSEC Update message is assured
   that the Secure_Path corresponds to a sequence of autonomous systems
   who have all agreed in principle to forward packets to the given
   prefix along the indicated path.

we do not know what the bgp announcement is signaling.  while
willingness to forward has been the classic, idr is declaring bgp to be
a competitor to the dns for arbitrary signaling.

--

   (It should be noted that BGPSEC
   does not offer a precise guarantee that the data packets would
   propagate along the indicated path; it only guarantees that the BGP
   update conveying the path indeed propagated along the indicated
   path.)

this is more like it

--

   Therefore, it is important to note that when a BGPSEC speaker signs
   an outgoing update message, it is not attesting to a belief that all
   signatures prior to its are valid.  Instead it is merely asserting
   that:

   o  The BGPSEC speaker received the given route advertisement with the
      indicated NLRI and Secure_Path; and

   o  The BGPSEC speaker chose to propagate an advertisement for this
      route to the peer (implicitly) indicated by the 'Target AS'

and that it is capable of that particular algorithm suite (trivial)

--

   Finally, BGPSEC does not provide protection against all attacks at
   the transport layer.

s/all//

--

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

slippery slope.

--

   Samuel Weiler
   Cobham

sparta again

-30-