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-
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
