draft-ietf-sidr-bgpsec-protocol-00.txt   draft-ietf-sidr-bgpsec-protocol-01.txt 
Network Working Group M. Lepinski, Ed. Network Working Group M. Lepinski, Ed.
Internet-Draft BBN Internet-Draft BBN
Intended status: Standards Track June 10, 2011 Intended status: Standards Track October 31, 2011
Expires: December 12, 2011 Expires: May 3, 2012
BGPSEC Protocol Specification BGPSEC Protocol Specification
draft-ietf-sidr-bgpsec-protocol-00 draft-ietf-sidr-bgpsec-protocol-01
Abstract Abstract
This document describes BGPSEC, an extension to the Border Gateway This document describes BGPSEC, an extension to the Border Gateway
Protocol (BGP) that provides security for the AS-PATH attribute in Protocol (BGP) that provides security for the AS-PATH attribute in
BGP update messages. BGPSEC is implemented via a new optional non- BGP update messages. BGPSEC is implemented via a new optional non-
transitive BGP path attribute that carries a digital signature transitive BGP path attribute that carries a digital signature
produced by each autonomous system on the AS-PATH. produced by each autonomous system on the AS-PATH.
Requirements Language Requirements Language
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 12, 2011. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. BGPSEC Negotiation . . . . . . . . . . . . . . . . . . . . . . 3 2. BGPSEC Negotiation . . . . . . . . . . . . . . . . . . . . . . 3
3. The BGPSEC_Path_Signatures Attribute . . . . . . . . . . . . . 5 3. The BGPSEC_Path_Signatures Attribute . . . . . . . . . . . . . 5
4. Generating a BGPSEC Update . . . . . . . . . . . . . . . . . . 7 4. Generating a BGPSEC Update . . . . . . . . . . . . . . . . . . 7
4.1. Originating a New BGPSEC Update . . . . . . . . . . . . . 8 4.1. Originating a New BGPSEC Update . . . . . . . . . . . . . 8
4.2. Propagating a Route Advertisement . . . . . . . . . . . . 11 4.2. Propagating a Route Advertisement . . . . . . . . . . . . 11
5. Validating a BGPSEC Update . . . . . . . . . . . . . . . . . . 13 4.2.1. Propogating an Update without the Path_Signatures
5.1. Validation Algorithm . . . . . . . . . . . . . . . . . . . 14 attribute . . . . . . . . . . . . . . . . . . . . . . 14
6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 18 5. Processing a Received BGPSEC Update . . . . . . . . . . . . . 15
6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 18 5.1. Validation Algorithm . . . . . . . . . . . . . . . . . . . 17
6.2. Extensibility Considerations . . . . . . . . . . . . . . . 19 6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6.2. Extensibility Considerations . . . . . . . . . . . . . . . 21
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 24 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. Normative References . . . . . . . . . . . . . . . . . . . . . 24 9.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 27
10. Normative References . . . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
This document describes BGPSEC, a mechanism for providing path This document describes BGPSEC, a mechanism for providing path
security for Border Gateway Protocol (BGP) [1] route advertisements. security for Border Gateway Protocol (BGP) [1] route advertisements.
That is, a BGP speaker who receives a valid BGPSEC update has That is, a BGP speaker who receives a valid BGPSEC update has
cryptographic assurance that the advertised route has the following cryptographic assurance that the advertised route has the following
two properties: two properties:
1. The route was originated by an AS that has been explicitly 1. The route was originated by an AS that has been explicitly
skipping to change at page 4, line 40 skipping to change at page 4, line 40
If there does not exist at least one version of BGPSEC that is If there does not exist at least one version of BGPSEC that is
supported by both peers in a BGP session, then the use of BGPSEC has supported by both peers in a BGP session, then the use of BGPSEC has
not been negotiated. (That is, in such a case, messages containing not been negotiated. (That is, in such a case, messages containing
the BGPSEC_Path_Signatures MUST NOT be sent.) the BGPSEC_Path_Signatures MUST NOT be sent.)
If version 0 is the only version of BGPSEC for which both peers (in a 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 BGP session) advertise support, then the use of BGPSEC has been
negotiated and the BGPSEC peers MUST adhere to the specification of negotiated and the BGPSEC peers MUST adhere to the specification of
BGPSEC provided in this document. (If there are multiple versions of BGPSEC provided in this document. (If there are multiple versions of
BGPSEC which are supported by both peer, then the behavior of those BGPSEC which are supported by both peers, then the behavior of those
peers is outside the scope of this document.) peers is outside the scope of this document.)
The second two octets contain the 16-bit Address Family Identifier The second two octets contain the 16-bit Address Family Identifier
(AFI) which indicates the address family for which the BGPSEC speaker (AFI) which indicates the address family for which the BGPSEC speaker
is advertising support for BGPSEC. This document only specifies is advertising support for BGPSEC. This document only specifies
BGPSEC for use with two address families, IPv4 and IPv6. BGPSEC for BGPSEC for use with two address families, IPv4 and IPv6. BGPSEC for
use with other address families may be specified in future documents. use with other address families may be specified in future documents.
Note that if the BGPSEC speaker wishes to use BGPSEC with two Note that if the BGPSEC speaker wishes to use BGPSEC with two
different address families (i.e., IPv4 and IPv6) over the same BGP different address families (i.e., IPv4 and IPv6) over the same BGP
session, then the speaker must include two instances of this session, then the speaker must include two instances of this
skipping to change at page 7, line 8 skipping to change at page 7, line 8
The Signature-List Block Length is the total number of octets in all The Signature-List Block Length is the total number of octets in all
Signature-Segments (i.e., the total size of the variable-length Signature-Segments (i.e., the total size of the variable-length
portion of the Signature-List block.) portion of the Signature-List block.)
A Signature-Segment has the following structure: A Signature-Segment has the following structure:
Signature Segments Signature Segments
+-------------------------------------------- + +-------------------------------------------- +
| pCount (1 octet) |
+---------------------------------------------+
| Subject Key Identifier Length (1 octet) | | Subject Key Identifier Length (1 octet) |
+---------------------------------------------+ +---------------------------------------------+
| Subject Key Identifier (variable) | | Subject Key Identifier (variable) |
+---------------------------------------------+ +---------------------------------------------+
| Signature (fixed by algorithm suite) | | Signature (fixed by algorithm suite) |
+---------------------------------------------+ +---------------------------------------------+
The pCount field contains an unsigned integer indicating 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 copies of their AS to the AS-PATH
without requiring the speaker to generate multiple signatures.
The Subject Key Identifier Length contains the size (in octets) of The Subject Key Identifier Length contains the size (in octets) of
the value in the Subject Key Identifier field of the Signature- the value in the Subject Key Identifier field of the Signature-
Segment. The Subject Key Identifier contains the value in the Segment. The Subject Key Identifier contains the value in the
Subject Key Identifier extension of the RPKI end-entity certificate Subject Key Identifier extension of the RPKI end-entity certificate
that is used to verify the signature (see Section 5 for details on that is used to verify the signature (see Section 5 for details on
validity of BGPSEC update messages). validity of BGPSEC update messages).
The Signature contains a digital signature that protects the NLRI, The Signature contains a digital signature that protects the NLRI,
the AS_Path and the BGPSEC_Path_Signatures attribute (see Sections 4 the AS_Path and the BGPSEC_Path_Signatures attribute (see Sections 4
and 5 for details on generating and verifying this signature, and 5 for details on generating and verifying this signature,
skipping to change at page 8, line 43 skipping to change at page 8, line 50
Note also new signatures are only added to a BGPSEC update message Note also new signatures are only added to a BGPSEC update message
when a BGPSEC speaker is generating an update message to send to an 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 external peer (i.e., when the AS number of the peer is not equal to
the BGPSEC speaker's own AS number). Therefore, a BGPSEC speaker who the BGPSEC speaker's own AS number). Therefore, a BGPSEC speaker who
only sends BGPSEC update messages to peers within its own AS, it does only sends BGPSEC update messages to peers within its own AS, it does
not need to possess any private signature keys. not need to possess any private signature keys.
4.1. Originating a New BGPSEC Update 4.1. Originating a New BGPSEC Update
In an update message that originates a new route advertisement (i.e., In an update message that originates a new route advertisement (i.e.,
an update whose AS_Path contains, possibly multiple occurrences of, a an update whose AS_Path contains a single AS number), the BGPSEC
single AS number), the BGPSEC speaker creates one Signature-List speaker creates one Signature-List Block for each algorithm suite
Block for each algorithm suite that will be used. Typically, a that will be used. Typically, a BGPSEC speaker will use only a
BGPSEC speaker will use only a single algorithm suite. However, to single algorithm suite. However, to ensure backwards compatibility
ensure backwards compatibility during a period of transition from a during a period of transition from a 'current' algorithm suite to a
'current' algorithm suite to a 'new' algorithm suite, it will be 'new' algorithm suite, it will be necessary to originate update
necessary to originate update messages containing Signature-List messages containing Signature-List Blocks for both the 'current' and
Blocks for both the 'current' and the 'new' algorithm suites (see the 'new' algorithm suites (see Section 6.1).
Section 6.1).
The Resource PKI enables the legitimate holder of IP address The Resource PKI enables the legitimate holder of IP address
prefix(es) to issue a signed object, called a Route Origination prefix(es) to issue a signed object, called a Route Origination
Authorization (ROA), that authorizes a given AS to originate routes Authorization (ROA), that authorizes a given AS to originate routes
to a given set of prefixes (see [6]).Note that validation of a BGPSEC to a given set of prefixes (see [6]). Note that validation of a
update message will fail (i.e., the validation algorithm, specified BGPSEC update message will fail (i.e., the validation algorithm,
in Section 5.1, returns 'Not Good') unless there exists a valid ROA specified in Section 5.1, returns 'Not Good') unless there exists a
authorizing the first AS in the AS PATH attribute to originate routes valid ROA authorizing the first AS in the AS PATH attribute to
to the prefix being advertised. Therefore, a BGPSEC speaker SHOULD originate routes to the prefix being advertised. Therefore, a BGPSEC
NOT originate a BGPSEC update advertising a route for a given prefix speaker SHOULD NOT originate a BGPSEC update advertising a route for
unless there exists a valid ROA authorizing the BGPSEC speaker's AS a given prefix unless there exists a valid ROA authorizing the BGPSEC
to originate routes to this prefix. speaker's AS to originate routes to this prefix.
The Expire Time field is set to specify a time at which the route The Expire Time field is set to specify a time at which the route
advertisement specified in the update message will cease to be valid. advertisement specified in the update message will cease to be valid.
Once the Expire Time has been reached, all BGPSEC speakers who have Once the Expire Time has been reached, all BGPSEC speakers who have
received the advertisement will treat it as invalid. The purpose of received the advertisement will treat it as invalid. The purpose of
this field is to protect the BGPSEC speaker against attacks in which this field is to protect the BGPSEC speaker against attacks in which
the BGPSEC speaker wishes to withdraw the route, but intermediate a malicious BGPSEC peer either replays a stale update message, or
(malicious) BGP speakers fail to propagate the withdrawal to their else fails to propagate the withdrawal for a prefix.
peers.
It is therefore necessary for the originating BGPSEC speaker to issue It is therefore necessary for the originating BGPSEC speaker to issue
a new BGPSEC update prior to reaching the Expire Time. It is a new BGPSEC update, for the given prefix, prior to reaching the
RECOMMENDED that a BGPSEC speaker originate a new route advertisement Expire Time. Setting appropriate values for Expire Time and for the
for a given NLRI at intervals equal to roughly one-third the validity rate at which new updates are sent out for a given prefix is an
period of the route advertisement. (Note that it is necessary to add operational choice that involves trade offs between the window of
some small amount of random jitter to the interval to avoid replay protection versus network and processing load. Therefore,
synchronization effects.) For instance, if a BGPSEC speaker is these settings are discussed in more detail in BGPSEC Operational
originating route advertisements that are valid for one day (i.e., Considerations document [9].
the Expire Time is 24 hours after the generation of the update
message), then it is recommended that the BGPSEC speaker re-issue new
a new BGPSEC update message for advertising the given prefix roughly
once every 8 hours (plus or minus a small random value).
(Editor's Note: The parameter recommendations in the previous
paragraph are preliminary and will need to be updated based on
further implementation and deployment experience.)
There is a natural trade-off in setting the Expire Time. Setting a
later Expire Time increases the amount of time by which a malicious
intermediate can delay a future route withdrawal. Similarly, setting
a later Expire Time also increases the window of opportunity for
malicious replay attacks in which a previous BGPSEC announcement is
replayed while suppressing a more recent withdrawal for the same
prefix. However, setting a sooner Expire Timed increases the
frequency with which the BGPSEC speaker needs to send new
announcements for the given prefix.
When originating a new route advertisement, each Signature-List Block When originating a new route advertisement, each Signature-List Block
MUST consist of a single Signature-Segment. The following describes MUST consist of a single Signature-Segment. The following describes
how the BGPSEC speaker populates the fields of the Signature-List how the BGPSEC speaker populates the fields of the Signature-List
Block (see Section 3 for more information on the syntax of Signature- Block (see Section 3 for more information on the syntax of Signature-
List Blocks). List Blocks).
The pCount field 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).
However, even when the pCount field is set to a value greater than 1,
the BGPSEC speaker still only places a single copy of its AS number
in the AS-PATH attribute. This is because the BGPSEC validation
algorithm (see Section 5) requires a one-to-one correspondence
between signatures and AS numbers in the AS-PATH. That is, setting a
pCount value greater than 1 achieves the same semantics as
repetition, but requires the generation of only a single signatures.
Whereas a BGPSEC update message with actual repetition in the AS-PATH
attribute would fail validation unless the BGPSEC speaker generated
multiple signatures (one for each copy of the AS number placed in the
AS-PATH).
The Subject Key Identifier field (see Section 3) is populated with The Subject Key Identifier field (see Section 3) is populated with
the identifier contained in the Subject Key Identifier extension of the identifier contained in the Subject Key Identifier extension of
the RPKI end-entity certificate used by the BGPSEC speaker. This the RPKI end-entity certificate used by the BGPSEC speaker. This
Subject Key Identifier will be used by recipients of the route Subject Key Identifier will be used by recipients of the route
advertisement to identify the proper certificate to use in verifying advertisement to identify the proper certificate to use in verifying
the signature. the signature.
The Subject Key Identifier Length field is populated with the length The Subject Key Identifier Length field is populated with the length
(in octets) of the Subject Key Identifier. (in octets) of the Subject Key Identifier.
The Signature field contains a digital signature that binds the NLRI, The Signature field contains a digital signature that binds the NLRI,
AS_Path attribute and BGPSEC_Path_Signatures attribute to the RPKI AS_Path attribute and BGPSEC_Path_Signatures attribute to the RPKI
end-entity certificate used by the BGPSEC speaker. The digital end-entity certificate used by the BGPSEC speaker. The digital
signature is computed as follows: signature is computed as follows:
o Construct a sequence of octets by concatenating the Expire Time, o Construct a sequence of octets by concatenating the Expire Time,
Target AS Number, Origin AS Number, Algorithm Suite Identifier, Target AS Number, Origin AS Number, Algorithm Suite Identifier,
and NLRI. The Target AS Number is the AS to whom the BGPSEC pCount and NLRI. The Target AS Number is the AS to whom the
speaker intends to send the update message. (Note that the Target BGPSEC speaker intends to send the update message. (Note that the
AS number is the AS number announced by the peer in the OPEN Target AS number is the AS number announced by the peer in the
message of the BGP session within which the update is sent.) The OPEN message of the BGP session within which the update is sent.)
Origin AS number prepend to this sequence the Target AS (the AS to The Origin AS number prepend to this sequence the Target AS (the
whom the BGPSEC speaker intends to send the update message) and AS to whom the BGPSEC speaker intends to send the update message)
the Origin AS Number refers to the AS of the BGPSEC speaker who is and the Origin AS Number refers to the AS of the BGPSEC speaker
originating the route advertisement. who is originating the route advertisement.
Sequence of Octets to be Signed Sequence of Octets to be Signed
+---------------------------------------+ +---------------------------------------+
| Expire Time (8 octets) | | Expire Time (8 octets) |
+---------------------------------------+ +---------------------------------------+
| Target AS Number (4 octets) | | Target AS Number (4 octets) |
+---------------------------------------+ +---------------------------------------+
| Origin AS Number (4 octets) | | Origin AS Number (4 octets) |
+---------------------------------------+ +---------------------------------------+
| Algorithm Suite Identifier (1 octet) | | Algorithm Suite Identifier (1 octet) |
+---------------------------------------+ +---------------------------------------+
| pCount (1 octet) |
+---------------------------------------+
| NLRI Length (1 octet) | | NLRI Length (1 octet) |
+---------------------------------------+ +---------------------------------------+
| NLRI Prefix (variable) | | NLRI Prefix (variable) |
+---------------------------------------+ +---------------------------------------+
o Apply to this octet sequence the digest algorithm (for the o Apply to this octet sequence the digest algorithm (for the
algorithm suite of this Signature-List) to obtain a digest value. algorithm suite of this Signature-List) to obtain a digest value.
o Apply to this digest value the signature algorithm, (for the o Apply to this digest value the signature algorithm, (for the
algorithm suite of this Signature-List) to obtain the digital algorithm suite of this Signature-List) to obtain the digital
skipping to change at page 11, line 52 skipping to change at page 12, line 5
possess a received update message for the same prefix that also possess a received update message for the same prefix that also
contains a BGPSEC_Path_Signatures attribute. contains a BGPSEC_Path_Signatures attribute.
Additionally, whenever a BGPSEC speaker selects as the best route to Additionally, whenever a BGPSEC speaker selects as the best route to
a given prefix a route that it received in an update message a given prefix a route that it received in an update message
containing the BGPSEC_Path_Signatures attribute, it is RECOMMENDED containing the BGPSEC_Path_Signatures attribute, it is RECOMMENDED
that if the BGPSEC speaker chooses to propagate the route that it that if the BGPSEC speaker chooses to propagate the route that it
generate an update message containing the BGPSEC_Path_Signatures generate an update message containing the BGPSEC_Path_Signatures
attribute. However, a BGPSEC speaker MAY propagate a route attribute. However, a BGPSEC speaker MAY propagate a route
advertisement by generating a (non-BGPSEC) update message that does advertisement by generating a (non-BGPSEC) update message that does
not contain the BGPSEC_Path_Signatures attribute. (See Section 7 for not contain the BGPSEC_Path_Signatures attribute. Note that if a
discussion of the security ramifications of removing BGPSEC BGPSEC speaker receives a route advertisement containing the
signatures.) BGPSEC_Path_Signatures attribute and chooses for any reason (e.g.,
its peer is a non-BGPSEC speaker) to propagate the route
advertisement as a non-BGPSEC update message without the
BGPSEC_Path_Signatures attribute, then it MUST follow the
instructions in Section 4.2.1.
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. Furthermore,
note that when a BGPSEC speaker propagates a route advertisement with
the BGPSEC_Path_Signatures attribute it is attesting to the fact
that: (1) it received a BGPSEC update message that advertised this
route; and (2) it chose this route as its best path to the given
prefix. That is, the BGPSEC speaker is not attesting to the
validation state of the update message it received. (See Section 7
for more discussion of the security semantics of BGPSEC signatures.)
If the BGPSEC speaker is producing an update message which contains If the BGPSEC speaker is producing an update message which contains
an AS-SET (e.g., the BGPSEC speaker is performing proxy aggregation), an AS-SET (e.g., the BGPSEC speaker is performing proxy aggregation),
then the BGPSEC speaker MUST NOT include the BGPSEC_Path_Signatures then the BGPSEC speaker MUST NOT include the BGPSEC_Path_Signatures
attribute. In such a case, the BGPSEC speaker must remove any attribute. In such a case, the BGPSEC speaker must remove any
existing BGPSEC_Path_Signatures in the received advertisement(s) for existing BGPSEC_Path_Signatures in the received advertisement(s) for
this prefix and produce a standard (non-BGPSEC) update message. this prefix and produce a standard (non-BGPSEC) update message.
To generate the BGPSEC_Path_Signatures attribute on the outgoing To generate the BGPSEC_Path_Signatures attribute on the outgoing
update message, the BGPSEC first copies the Expire Time directly from update message, the BGPSEC first copies the Expire Time directly from
the received update message to the new update message (that it is the received update message to the new update message (that it is
constructing). Note that the BGPSEC speaker MUST NOT change the constructing). Note that the BGPSEC speaker MUST NOT change the
Expire Time as any change to Expire Time will cause the new BGPSEC Expire Time as any change to Expire Time will cause the new BGPSEC
update message to fail validation (see Section 5). update message to fail validation (see Section 5).
The BGPSEC speaker next removes from the BGPSEC_Path_Signatures If the received BGPSEC update message contains two Signature-List
attribute any Signature-List Blocks corresponding to algorithm suites Blocks and the BGPSEC speaker supports both of the corresponding
that it does not support. The BGPSEC_Path_Signatures attribute for algorithms suites, then the BGPSEC speaker SHOULD generate a new
the new update message SHOULD contain a Signature-List Block for update message that includes both of the Signature-List Blocks. If
every algorithm suite that is both present in the received update the received BGPSEC update message contains two Signature-List Blocks
message and which is supported by the BGPSEC speaker. and the BGPSEC speaker only supports one of the two corresponding
algorithm suites, then the BGPSEC speaker MUST remove the Signature-
List 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-List Blocks contained in the received
update message, then the BGPSEC speaker MUST NOT propagate the route
advertisement with the BGPSEC_Path_Signatures attribute. (See
Section 4.2.1 for information on removing the BGPSEC_Path_Signatures
attribute when propagating route advertisements.)
Note that the validation algorithm (see Section 5.1) deems a BGPSEC Note that in the case where there are two Signature-List Blocks
update message to be 'Good' if there is at least one supported (corresponding to different algorithm suites) that the validation
algorithm suite (and corresponding Signature-List Block) that is algorithm (see Section 5.1) deems a BGPSEC update message to be
deemed 'Good'. This means that a 'Good' BGPSEC update message may 'Good' if there is at least one supported algorithm suite (and
contain Signature-List Blocks which are deemed 'Not Good' (e.g., corresponding Signature-List Block) that is deemed 'Good'. This
contain signatures that the BGPSEC is unable to verify). means that a 'Good' BGPSEC update message may contain a Signature-
Nonetheless, such Signature-List Blocks MUST NOT be removed. (See List Block which is deemed 'Not Good' (e.g., contains signatures that
Section 7 for a discussion of the security ramifications of this the BGPSEC is unable to verify). Nonetheless, such Signature-List
design choice.) Blocks MUST NOT be removed. (See Section 7 for a discussion of the
security ramifications of this design choice.)
For each Signature-List Block corresponding to an algorithm suite For each Signature-List Block corresponding to an algorithm suite
that the BGPSEC speaker does support, the BGPSEC speaker then adds a that the BGPSEC speaker does support, the BGPSEC speaker then adds a
new Signature-Segment to the Signature-List Block. This Signature- new Signature-Segment to the Signature-List Block. This Signature-
Segment is prepended to the list of Signature-Segments (placed in the Segment is prepended to the list of Signature-Segments (placed in the
first position) so that the list of Signature-Segments appears in the first position) so that the list of Signature-Segments appears in the
same order as the corresponding AS numbers in the AS-Path attribute. same order as the corresponding AS numbers in the AS-Path attribute.
The BGPSEC speaker populates the fields of this new signature-segment The BGPSEC speaker populates the fields of this new signature-segment
as follows. as follows.
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
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. (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 AS-PATH, 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. 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).
The Subject Key Identifier field in the new segment is populated with The Subject Key Identifier field in the new segment is populated with
the identifier contained in the Subject Key Identifier extension of the identifier contained in the Subject Key Identifier extension of
the RPKI end-entity certificate used by the BGPSEC speaker. This the RPKI end-entity certificate used by the BGPSEC speaker. This
Subject Key Identifier will be used by recipients of the route Subject Key Identifier will be used by recipients of the route
advertisement to identify the proper certificate to use in verifying advertisement to identify the proper certificate to use in verifying
the signature. the signature.
The Subject Key Identifier Length field is populated with the length The Subject Key Identifier Length field is populated with the length
(in octets) of the Subject Key Identifier. (in octets) of the Subject Key Identifier.
The Signature field in the new segment contains a digital signature The Signature field in the new segment contains a digital signature
that binds the NLRI, AS_Path attribute and BGPSEC_Path_Signatures that binds the NLRI, AS_Path attribute and BGPSEC_Path_Signatures
attribute to the RPKI end-entity certificate used by the BGPSEC attribute to the RPKI end-entity certificate used by the BGPSEC
speaker. The digital signature is computed as follows: speaker. The digital signature is computed as follows:
o Construct a sequence of octets by concatenating the signature o Construct a sequence of octets by concatenating the signature
field of the most recent Signature-Segment (the one corresponding field of the most recent Signature-Segment (the one corresponding
to AS from whom the BGPSEC speaker's AS received the announcement) to AS from whom the BGPSEC speaker's AS received the announcement)
with the Target AS (the AS to whom the BGPSEC speaker intends to with the pCount field inserted by the signer, and the Target AS
send the update message). Note that the Target AS number is the (the AS to whom the BGPSEC speaker intends to send the update
AS number announced by the peer in the OPEN message of the BGP message). Note that the Target AS number is the AS number
session within which the BGPSEC update message is sent. announced by the peer in the OPEN message of the BGP session
within which the BGPSEC update message is sent.
Sequence of Octets to be Signed Sequence of Octets to be Signed
+-----------------------------------------------------------+ +-----------------------------------------------------------+
| Most Recent Signature Field (fixed by algorithm suite) | | Most Recent Signature Field (fixed by algorithm suite) |
------------------------------------------------------------+ +-----------------------------------------------------------+
| pCount Field of Signer (1 octet) |
+-----------------------------------------------------------+
| Target AS Number (4 octets) | | Target AS Number (4 octets) |
+-----------------------------------------------------------+ +-----------------------------------------------------------+
o Apply to this octet sequence the digest algorithm (for the o Apply to this octet sequence the digest algorithm (for the
algorithm suite of this Signature-List) to obtain a digest value. algorithm suite of this Signature-List) to obtain a digest value.
o Apply to this digest value the signature algorithm, (for the o Apply to this digest value the signature algorithm, (for the
algorithm suite of this Signature-List) to obtain the digital algorithm suite of this Signature-List) to obtain the digital
signature. Then populate the Signature Field with this digital signature. Then populate the Signature Field with this digital
signature. signature.
5. Validating a BGPSEC Update 4.2.1. Propogating an Update without the Path_Signatures attribute
As discussed earlier in Section 4.2, a BGPSEC speaker may receive a
BGPSEC update message that contains the BGPSEC_Path_Signatures
Attribute and propagate the associated route in a non-BGPSEC update
message that does not contain the BGPSEC_Path_Signatures attribute.
A BGPSEC speaker MUST remove the BGPSEC_Path_Signatures attribute
when propagating a route advertisement to a peer that has not
advertised support BGPSEC (see Section 2), when propagating a route
advertisement that contains an AS-SET in the AS-PATH, or when the
BGPSEC speaker does not support any algorithm suite used to generate
signatures in the received update message. In all other cases, the
BGPSEC speaker SHOULD NOT remove the BGPSEC_Path_Signatures
attribute.
When the BGPSEC speaker receives a BGPSEC update message that
contains the BGPSEC_Path_Signatures Attribute and propagates the
associated route in a non-BGPSEC update message, the BGPSEC MUST
perform a transformation on the AS-PATH in the non-BGPSEC update
message that it generates. The reason for this is that the AS-PATH
attribute has slightly different semantics in a BGPSEC update message
than it has in a non-BGPSEC update message.
To generate the AS-PATH in the outgoing non-BGPSEC update message,
the BGPSEC speaker performs the following steps for each AS number in
the AS-PATH of the received BGPSEC update message. (Note that there
is a one-to-one correspondence between the AS numbers in the AS-PATH
of a BGPSEC update message and the Signature Segments in the
Signature-List Block of the BGPSEC_Path_Signatures attribute. The
follows step will make use of this correspondence.)
o For each AS number in the AS-PATH of the received BGPSEC update
message, locate the pCount value in the corresponding Signature
Segment.
o If the pCount value is equal to 0, then do not include the
corresponding AS in the AS-PATH of the outgoing non-BGPSEC update
message.
o If the pCount value is greater than or equal to 1, insert into the
AS-PATH of the outgoing update message a number of copies of the
corresponding AS number equal to the pCount value.
Other than the above transformation that is applied to the AS-PATH,
no additional special behavior is required when removing BGPSEC
signatures from BGPSEC update messages. That is, all other
attributes in the outgoing non-BGPSEC update message are generated as
they would normally be generated by the BGP speaker in a non-BGPSEC
update message.
5. Processing a Received BGPSEC Update
Validation of a BGPSEC update messages makes use of data from RPKI Validation of a BGPSEC update messages makes use of data from RPKI
certificates and signed Route Origination Authorizations (ROA). In certificates and signed Route Origination Authorizations (ROA). In
particular, to validate update messages containing the particular, to validate update messages containing the
BGPSEC_Path_Signatures attribute, it is necessary that the recipient BGPSEC_Path_Signatures attribute, it is necessary that the recipient
have access to the following data obtained from valid RPKI have access to the following data obtained from valid RPKI
certificates and ROAs: certificates and ROAs:
o For each valid RPKI end-entity certificate containing an AS Number o For each valid RPKI end-entity certificate containing an AS Number
extension, the AS Number, Public Key and Subject Key Identifier extension, the AS Number, Public Key and Subject Key Identifier
are required are required
o For each valid ROA, the AS Number and the list of IP address o For each valid ROA, the AS Number and the list of IP address
prefixes prefixes
Note that the BGPSEC speaker could perform the validation of RPKI Note that the BGPSEC speaker could perform the validation of RPKI
certificates and ROAs on its own and extract the required data, or it 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 could receive the same data from a trusted cache that performs RPKI
validation on behalf of (some set of) BGPSEC speakers. validation on behalf of (some set of) BGPSEC speakers. (The latter
case in analogous to the use of the RPKI-RTR protocol [10] for origin
validation.)
To validate a BGPSEC update message containing the To validate a BGPSEC update message containing the
BGPSEC_Path_Signatures attribute, the recipient performs the BGPSEC_Path_Signatures attribute, the recipient performs the
validation steps specified in Section 5.1. The validation procedure validation steps specified in Section 5.1. The validation procedure
results in one of two states: 'Good' and 'Not Good'. results in one of two states: 'Good' and 'Not Good'.
It is expected that the output of the validation procedure will be It is expected that the output of the validation procedure will be
used as an input to BGP route selection. However, BGP route used as an input to BGP route selection. However, BGP route
selection and thus the handling of the two validation states is a selection and thus the handling of the two validation states is a
matter of local policy, and shall be handled using existing local matter of local policy, and shall be handled using existing local
skipping to change at page 14, line 44 skipping to change at page 17, line 6
policy in the AS determines the specific means for conveying the policy in the AS determines the specific means for conveying the
validation status through various pre-existing mechanisms (e.g., validation status through various pre-existing mechanisms (e.g.,
modifying an attribute). As discussed in Section 4, when a BGPSEC modifying an attribute). As discussed in Section 4, when a BGPSEC
speaker chooses to forward a (syntactically correct) BGPSEC update speaker chooses to forward a (syntactically correct) BGPSEC update
message, it SHOULD be forwarded with its BGPSEC_Path_Signatures message, it SHOULD be forwarded with its BGPSEC_Path_Signatures
attribute intact (regardless of the validation state of the update attribute intact (regardless of the validation state of the update
message). Based entirely on local policy settings, an egress router message). Based entirely on local policy settings, an egress router
MAY trust the validation status conveyed by an ingress router or it MAY trust the validation status conveyed by an ingress router or it
MAY perform its own validation. MAY perform its own validation.
Upon receiving a BGPSEC update message, a BGPSEC speaker SHOULD sum
the pCount values within BGPSEC_Path_Signatures attribute to
determine the effective length of the AS Path. The BGPSEC speaker
SHOULD use this sum of pCount values in precisely the same way as it
uses the length of the AS Path in non-BGPSEC update messages.
5.1. Validation Algorithm 5.1. Validation Algorithm
This section specifies an algorithm for validation of BGPSEC update This section specifies an algorithm for validation of BGPSEC update
messages. A conformant implementation MUST include an BGPSEC update messages. A conformant implementation MUST include an BGPSEC update
validation algorithm that is functionally equivalent to the external validation algorithm that is functionally equivalent to the external
behavior of this algorithm. behavior of this algorithm.
First, the recipient of a BGPSEC update message performs a check to First, the recipient of a BGPSEC update message performs a check to
ensure that the message is properly formed. Specifically, the ensure that the message is properly formed. Specifically, the
recipient performs the following checks: recipient performs the following checks:
skipping to change at page 15, line 25 skipping to change at page 17, line 42
entirety of each Signature-List Block must be checked to ensure entirety of each Signature-List Block must be checked to ensure
that it is well formed, even though the validation process may that it is well formed, even though the validation process may
terminate before all signatures are cryptographically verified.) terminate before all signatures are cryptographically verified.)
If there are two Signature-List Blocks within the If there are two Signature-List Blocks within the
BGPSEC_Path_Signatures attribute and one of them is poorly formed (or BGPSEC_Path_Signatures attribute and one of them is poorly formed (or
contains the wrong number of Signature-Segments) , then the recipient contains the wrong number of Signature-Segments) , then the recipient
should log that an error occurred, strip off that particular should log that an error occurred, strip off that particular
Signature-List Block and process the update message as though it Signature-List Block and process the update message as though it
arrived with a single Signature-List Block. If the arrived with a single Signature-List Block. If the
BGPSEC_Path_Signatures attribute contains a syntax error which is not BGPSEC_Path_Signatures attribute contains a syntax error that is not
local to a single Signature-List Block, or if the AS-Path attribute local to one of two Signature-List Blocks, then the recipient should
log that an error occurred and drop the update message containing the
error. Similarly, if an update message contains both the
BGPSEC_Path_Signatures attribute and an AS-Path attribute that
contains an AS-Set segment, then the recipient should log that an contains an AS-Set segment, then the recipient should log that an
error occurred, strip off the BGPSEC_Path_Signatures attribute and error occurred and drop the update message containing the error.
process the update message as though it arrived without a
BGPSEC_Path_Signatures attribute.
Second, the BGPSEC speaker verifies that the update message has not Second, the BGPSEC speaker verifies that the update message has not
yet expired. To do this, locate the Expire Time field in the yet expired. To do this, locate the Expire Time field in the
BGPSEC_Path_Signatures attribute, and compare it with the current BGPSEC_Path_Signatures attribute, and compare it with the current
time. If the current time is later than the Expire Time, the BGPSEC time. If the current time is later than the Expire Time, the BGPSEC
update is 'Not Good' and the validation algorithm terminates. update is 'Not Good' and the validation algorithm terminates.
Third, the BGPSEC speaker verifies that the origin AS is authorized Third, the BGPSEC speaker verifies that the origin AS is authorized
to advertise the prefix in question. To do this, consult the valid 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 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 given IP address prefix in the update message. Then locate the last
(least recently added) AS number in the AS-Path. If the origin AS in (least recently added) AS number in the AS-Path. If the origin AS in
the AS-Path is not in the set of AS numbers associated with the given the AS-Path is not in the set of AS numbers associated with the given
prefix, then BGPSEC update message is 'Not Good' and the validation prefix, then BGPSEC update message is 'Not Good' and the validation
algorithm terminates. algorithm terminates.
Finally, the BGPSEC speaker examines the Signature-List Blocks in the Finally, the BGPSEC speaker examines the Signature-List Blocks in the
BGPSEC_Path_Signatures attribute. Any Signature-List Block BGPSEC_Path_Signatures attribute. Any Signature-List Block
corresponding to an algorithm suite that the BGPSEC speaker does not corresponding to an algorithm suite that the BGPSEC speaker does not
support MUST be discarded. If all Signature-List Blocks are support is not considered in validation. If there does not exist a
discarded in this manner then the BGPSEC speaker MUST treat the Signature-List Block corresponding to an algorithm suite that the
update message as though it arrived without a BGPSEC_Path_Signatures BGPSEC speaker supports, then the BGPSEC speaker MUST treat the
update message in the same manner that the BGPSEC speaker would treat
an update message that arrived without a BGPSEC_Path_Signatures
attribute. attribute.
For each remaining Signature-List Block (corresponding to an For each remaining Signature-List Block (corresponding to an
algorithm suite supported by the BGPSEC speaker), the BGPSEC speaker algorithm suite supported by the BGPSEC speaker), the BGPSEC speaker
iterates through the Signature-Segments in the Signature-List block, iterates through the Signature-Segments in the Signature-List block,
starting with the most recently added segment (and concluding with starting with the most recently added segment (and concluding with
the least recently added segment). Note that there is a one-to-one the least recently added segment). Note that there is a one-to-one
correspondence between Signature-Segments and AS numbers in the AS- correspondence between Signature-Segments and AS numbers in the AS-
Path attribute, and the following steps make use of this Path attribute, and the following steps make use of this
correspondence. correspondence.
skipping to change at page 16, line 38 skipping to change at page 19, line 10
o (Step II): Compute the digest function (for the given algorithm o (Step II): Compute the digest function (for the given algorithm
suite) on the appropriate data. If the segment is not the (least suite) on the appropriate data. If the segment is not the (least
recently added) segment corresponding to the origin AS, then the recently added) segment corresponding to the origin AS, then the
digest function should be computed on the following sequence of digest function should be computed on the following sequence of
octets: octets:
Sequence of Octets to be Hashed Sequence of Octets to be Hashed
+-------------------------------------------------+ +-------------------------------------------------+
| Signature Field in the Next Segment (variable) | | Signature Field in the Next Segment (variable) |
--------------------------------------------------+ +-------------------------------------------------+
| pCount Field in the Current Segment (1 octet) |
+-------------------------------------------------+
| AS Number of Subsequent AS (4 octets) | | AS Number of Subsequent AS (4 octets) |
+-------------------------------------------------+ +-------------------------------------------------+
The 'Signature Field in the Next Segment' is the Signature field The 'Signature Field in the Next Segment' is the Signature field
found in the Signature-Segment that is next to be processed (that is, found in the Signature-Segment that is next to be processed (that is,
the next most recently added Signature- Segment). the next most recently added Signature- Segment). The 'pCount Field
in the Current Segment' is the pCount field found in the Signature-
Segment that is currently being processed.
For the first segment to be processed (the most recently added For the first segment to be processed (the most recently added
segment), the 'AS Number of Subsequent AS' is the AS number of the segment), the 'AS Number of Subsequent AS' is the AS number of the
BGPSEC speaker validating the update message. Note that if a BGPSEC BGPSEC speaker validating the update message. Note that if a BGPSEC
speaker uses multiple AS Numbers (e.g., the BGPSEC speaker is a speaker uses multiple AS Numbers (e.g., the BGPSEC speaker is a
member of a confederation), the AS number used here MUST be the AS member of a confederation), the AS number used here MUST be the AS
number announced in the OPEN message for the BGP session over which number announced in the OPEN message for the BGP session over which
the BGPSEC update was received. the BGPSEC update was received.
For each other Signature-Segment, the 'AS Number of Subsequent AS' is For each other Signature-Segment, the 'AS Number of Subsequent AS' is
skipping to change at page 17, line 28 skipping to change at page 20, line 16
+----------------------------------------+ +----------------------------------------+
| Expire Time (8 octets) | | Expire Time (8 octets) |
-----------------------------------------+ -----------------------------------------+
| AS Number of Subsequent AS (4 octets) | | AS Number of Subsequent AS (4 octets) |
+----------------------------------------+ +----------------------------------------+
| Origin AS Number (4 octets) | | Origin AS Number (4 octets) |
+----------------------------------------+ +----------------------------------------+
| Algorithm Suite Identifier (1 octet) | | Algorithm Suite Identifier (1 octet) |
+----------------------------------------+ +----------------------------------------+
| pCount (1 octet) |
+----------------------------------------+
| NLRI Length (1 octet) | | NLRI Length (1 octet) |
+----------------------------------------+ +----------------------------------------+
| NLRI Prefix (variable) | | NLRI Prefix (variable) |
+----------------------------------------+ +----------------------------------------+
The NLRI Length, NLRI Prefix, Expire Time, and Algorithm Suite The NLRI Length, NLRI Prefix, Expire Time, and Algorithm Suite
Identifier are all obtained in a straight forward manner from the Identifier are all obtained in a straight forward manner from the
NLRI of the update message or the BGPSEC_Path_Signatures attribute NLRI of the update message or the BGPSEC_Path_Signatures attribute
being validated. being validated. The pCount field is taken from the Signature-
Segment currently being processed.
The Origin AS Number is the same Origin AS Number that was located in The Origin AS Number is the same Origin AS Number that was located in
Step I above. (That is, the AS number corresponding to the least Step I above. (That is, the AS number corresponding to the least
recently added Signature-Segment.) recently added Signature-Segment.)
The 'AS Number of Subsequent AS' is the AS Number added to the AS- The 'AS Number of Subsequent AS' is the AS Number added to the AS-
Path immediately after the Origin AS Number. (That is, the second AS Path immediately after the Origin AS Number. (That is, the second AS
Number that was added to the AS Path.) Number that was added to the AS Path.)
o (Step III): Use the signature validation algorithm (for the given o (Step III): Use the signature validation algorithm (for the given
skipping to change at page 22, line 32 skipping to change at page 25, line 21
should implement an update validation algorithm that performs should implement an update validation algorithm that performs
expensive checks (e.g., signature verification) after less expensive expensive checks (e.g., signature verification) after less expensive
checks (e.g., syntax checks). The validation algorithm specified in checks (e.g., syntax checks). The validation algorithm specified in
Section 5.1 was chosen so as to perform checks which are likely to be Section 5.1 was chosen so as to perform checks which are likely to be
expensive after checks that are likely to be inexpensive. However, expensive after checks that are likely to be inexpensive. However,
the relative cost of performing required validation steps may vary the relative cost of performing required validation steps may vary
between implementations, and thus the algorithm specified in Section between implementations, and thus the algorithm specified in Section
5.1 may not provide the best denial of service protection for all 5.1 may not provide the best denial of service protection for all
implementations. implementations.
Finally, 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.
8. IANA Considerations 8. IANA Considerations
IANA is requested to create a registry of BGPSEC algorithm suite IANA is requested to create a registry of BGPSEC algorithm suite
identifiers. This registry shall contain four fields, a one octet identifiers. This registry shall contain four fields, a one octet
Algorithm Suite Identifier, the name of the suite's digest algorithm, Algorithm Suite Identifier, the name of the suite's digest algorithm,
the name of the suite's signature algorithm, and a specification the name of the suite's signature algorithm, and a specification
pointer containing a reference to the formal specification of the pointer containing a reference to the formal specification of the
algorithm suite. That is, entries in the registry have the following algorithm suite. That is, entries in the registry have the following
form: form:
skipping to change at page 23, line 10 skipping to change at page 26, line 18
| | | | | | | | | |
+-----------------+--------------+----------------+---------------+ +-----------------+--------------+----------------+---------------+
The entries in this registry shall be managed by IETF consensus. The entries in this registry shall be managed by IETF consensus.
9. Contributors 9. Contributors
9.1. Authors 9.1. Authors
Rob Austein Rob Austein
Internet Systems Consortium Dragon Research Labs
sra@hactrn.net sra@hactrn.net
Steven Bellovin Steven Bellovin
Columbia University Columbia University
smb@cs.columbia.edu smb@cs.columbia.edu
Randy Bush Randy Bush
Internet Initiative Japan Internet Initiative Japan
randy@psg.com randy@psg.com
skipping to change at page 23, line 36 skipping to change at page 27, line 4
BBN Technologies BBN Technologies
lepinski@bbn.com lepinski@bbn.com
Stephen Kent Stephen Kent
BBN Technologies BBN Technologies
kent@bbn.com kent@bbn.com
Warren Kumari Warren Kumari
Google Google
warren@kumari.net warren@kumari.net
Doug Montgomery Doug Montgomery
USA National Institute of Standards and Technology USA National Institute of Standards and Technology
dougm@nist.gov dougm@nist.gov
Kotikalapudi Sriram Kotikalapudi Sriram
USA National Institute of Standards and Technology USA National Institute of Standards and Technology
kotikalapudi.sriram@nist.gov kotikalapudi.sriram@nist.gov
Samuel Weiler Samuel Weiler
weiler@watson.org
Cobham Cobham
weiler+ietf@watson.org
9.2. Acknowledgements 9.2. Acknowledgements
The authors would like to thank Luke Berndt, Sharon Goldberg, Ed The authors would like to thank Luke Berndt, Sharon Goldberg, Ed
Kern, Chris Morrow, Doug Maughan, Pradosh Mohapatra, Russ Mundy, Kern, Chris Morrow, Doug Maughan, Pradosh Mohapatra, Russ Mundy,
Sandy Murphy, Keyur Patel, Mark Reynolds, Heather Schiller, Jason Sandy Murphy, Keyur Patel, Mark Reynolds, Heather Schiller, Jason
Schiller, John Scudder, Ruediger Volk and David Ward for their Schiller, John Scudder, Ruediger Volk and David Ward for their
valuable input and review. valuable input and review.
10. Normative References 10. Normative References
[1] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border [1] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border
Gateway Protocol 4", RFC 4271, January 2006. Gateway Protocol 4", RFC 4271, January 2006.
[2] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol [2] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
Extensions for BGP-4", RFC 4760, January 2007. "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[3] Scudder, J. and R. Chandra, "Capabilities Advertisement with [3] Scudder, J. and R. Chandra, "Capabilities Advertisement with
BGP-4", RFC 5492, February 2009. BGP-4", RFC 5492, February 2009.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[5] Patel, K., Ward, D., and R. Bush, "Extended Message support for [5] Patel, K., Ward, D., and R. Bush, "Extended Message support for
BGP", March 2011. BGP", March 2011.
[6] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin [6] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Authorizations", February 2011. Origin Authorizations", February 2011.
[7] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure [7] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure
Internet Routing", February 2011. Internet Routing", February 2011.
[8] Kent, S., "Threat Model for BGP Path Security", February 2011. [8] Kent, S., "Threat Model for BGP Path Security", June 2011.
[9] Bush, R., "BGPsec Operational Considerations", October 2011.
[10] Bush, R. and R. Austein, "The RPKI/Router Protocol",
October 2011.
Author's Address Author's Address
Matthew Lepinski (editor) Matthew Lepinski (editor)
BBN BBN
10 Moulton St 10 Moulton St
Cambridge, MA 55409 Cambridge, MA 55409
US US
Phone: +1-617-873-5939 Phone: +1 617 873 5939
Email: mlepinski@bbn.com Email: mlepinski@bbn.com
 End of changes. 45 change blocks. 
125 lines changed or deleted 273 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/