draft-ietf-sidr-bgpsec-protocol-13.txt   draft-ietf-sidr-bgpsec-protocol-14.txt 
Network Working Group M. Lepinski, Ed. Network Working Group M. Lepinski, Ed.
Internet-Draft NCF Internet-Draft NCF
Intended status: Standards Track July 6, 2015 Intended status: Standards Track December 6, 2015
Expires: January 6, 2016 Expires: May 6, 2016
BGPsec Protocol Specification BGPsec Protocol Specification
draft-ietf-sidr-bgpsec-protocol-13 draft-ietf-sidr-bgpsec-protocol-14
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 path of autonomous Protocol (BGP) that provides security for the path of autonomous
systems through which a BGP update message passes. BGPsec is systems through which a BGP update message passes. BGPsec is
implemented via a new optional non-transitive BGP path attribute that implemented via a new optional non-transitive BGP path attribute that
carries a digital signature produced by each autonomous system that carries a digital signature produced by each autonomous system that
propagates the update message. propagates the update message.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 January 6, 2016. This Internet-Draft will expire on May 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. BGPsec Negotiation . . . . . . . . . . . . . . . . . . . . . . 3 2. BGPsec Negotiation . . . . . . . . . . . . . . . . . . . . . . 3
2.1. The BGPsec Capability . . . . . . . . . . . . . . . . . . 3 2.1. The BGPsec Capability . . . . . . . . . . . . . . . . . . 3
2.2. Negotiating BGPsec Support . . . . . . . . . . . . . . . . 4 2.2. Negotiating BGPsec Support . . . . . . . . . . . . . . . . 4
3. The BGPsec_Path Attribute . . . . . . . . . . . . . . . . . . 6 3. The BGPsec_Path Attribute . . . . . . . . . . . . . . . . . . 6
3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Secure_Path . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 8 3.2. Signature_Block . . . . . . . . . . . . . . . . . . . . . 8
4. Generating a BGPsec Update . . . . . . . . . . . . . . . . . . 11 4. BGPsec Update Messages . . . . . . . . . . . . . . . . . . . . 10
4.1. Originating a New BGPsec Update . . . . . . . . . . . . . 12 4.1. General Guidance . . . . . . . . . . . . . . . . . . . . . 10
4.2. Propagating a Route Advertisement . . . . . . . . . . . . 15 4.2. Constructing the BGPsec_Path Attribute . . . . . . . . . . 12
4.3. Processing Instructions for Confederation Members . . . . 19 4.3. Processing Instructions for Confederation Members . . . . 15
4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . . 21 4.4. Reconstructing the AS_PATH Attribute . . . . . . . . . . . 18
5. Processing a Received BGPsec Update . . . . . . . . . . . . . 22 5. Processing a Received BGPsec Update . . . . . . . . . . . . . 19
5.1. Overview of BGPsec Validation . . . . . . . . . . . . . . 25 5.1. Overview of BGPsec Validation . . . . . . . . . . . . . . 20
5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . . 26 5.2. Validation Algorithm . . . . . . . . . . . . . . . . . . . 22
6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 30 6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 25
6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 30 6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 25
6.2. Extensibility Considerations . . . . . . . . . . . . . . . 30 6.2. Extensibility Considerations . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7.1 Security Guarantees . . . . . . . . . . . . . . . . . . . . 31 7.1 Security Guarantees . . . . . . . . . . . . . . . . . . . . 26
7.2 On the Removal of BGPsec Signatures . . . . . . . . . . . . 32 7.2 On the Removal of BGPsec Signatures . . . . . . . . . . . . 27
7.3 Mitigation of Denial of Service Attacks . . . . . . . . . . 35 7.3 Mitigation of Denial of Service Attacks . . . . . . . . . . 29
7.4 Additional Security Considerations . . . . . . . . . . . . . 35 7.4 Additional Security Considerations . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 37 9.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 31
10. Normative References . . . . . . . . . . . . . . . . . . . . 38 10. Normative References . . . . . . . . . . . . . . . . . . . . 31
11. Informative References . . . . . . . . . . . . . . . . . . . 38 11. Informative References . . . . . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34
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) [2] route advertisements. security for Border Gateway Protocol (BGP) [2] 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
property: Every AS on the path of ASes listed in the update message property: Every AS on the path of ASes listed in the update message
has explicitly authorized the advertisement of the route to the has explicitly authorized the advertisement of the route to the
subsequent AS in the path. subsequent AS in the path.
skipping to change at page 11, line 5 skipping to change at page 10, line 6
to verify the signature (see Section 5 for details on validity of to verify the signature (see Section 5 for details on validity of
BGPsec update messages). BGPsec update messages).
The Signature Length field contains the size (in octets) of the value The Signature Length field contains the size (in octets) of the value
in the Signature field of the Signature Segment. in the Signature field of the Signature Segment.
The Signature contains a digital signature that protects the NLRI and The Signature contains a digital signature that protects the NLRI and
the BGPsec_Path attribute (see Sections 4 and 5 for details on the BGPsec_Path attribute (see Sections 4 and 5 for details on
signature generation and validation, respectively). signature generation and validation, respectively).
4. Generating a BGPsec Update 4. BGPsec Update Messages
Sections 4.1 and 4.2 cover two of the cases in which a BGPsec speaker Section 4.1 provides general guidance on the creation of BGPsec
generates an update message containing the BGPsec_Path attribute. Update Messages -- that is, update messages containing the
The first case is that in which the BGPsec speaker originates a new BGPsec_Path attribute.
route advertisement (Section 4.1). That is, the BGPsec speaker is
constructing an update message in which the only AS to appear in the
BGPsec_Path is the speaker's own AS. The second case is that in
which the BGPsec speaker receives a route advertisement from a peer
and then decides to propagate the route advertisement to an external
(eBGP) peer (Section 4.2). That is, the BGPsec speaker has received
a BGPsec update message and is constructing a new update message for
the same NLRI in which the BGPsec_Path attribute will contain AS
number(s) other than the speaker's own AS.
The remaining case is where the BGPsec speaker sends the update Section 4.2 specifies how a BGPsec speaker generates the BGPsec_Path
message to an internal (iBGP) peer. When originating a new route attribute to include in a BGPsec Update message.
advertisement and sending it to an internal peer, the BGPsec speaker
omits the BGPsec_Path attribute. When propagating a received route
advertisement to an internal peer, the BGPsec speaker typically
populates the BGPsec_Path attribute by copying the BGPsec_Path
attribute from the received update message. That is, the BGPsec_Path
attribute is copied verbatim. However, in the case that the BGPsec
speaker is performing an AS Migration, the BGPsec speaker may add an
additional signature on ingress before copying the BGPsec_Path
attribute (see [18] for more details).
Note that when a BGPsec speaker chooses to forward a BGPsec update Section 4.3 contains special processing instructions for members of
message to an iBGP peer, the BGPsec attribute SHOULD NOT be removed, an autonomous system confederation [5]. A BGPsec speaker that is not
unless the peer doesn't support BGPsec. In particular, the BGPsec a member of such a confederation MUST set the Flags field of the
attribute SHOULD NOT be removed even in the case where the BGPsec Secure_Path Segment to zero in all BGPsec update messages it sends.
update message has not been that has not successfully validated. (See
Section 5 for more information on validation, and Section 7 for the Section 4.4 contains instructions for reconstructing the AS_Path
security ramifications of removing BGPsec signatures.) attribute in cases where a BGPsec speaker receives an update message
with a BGPsec_Path attribute and wishes to propagate the update
message to a peer who does not support BGPsec.
4.1. General Guidance
The information protected by the signature on a BGPsec update message The information protected by the signature on a BGPsec update message
includes the AS number of the peer to whom the update message is includes the AS number of the peer to whom the update message is
being sent. Therefore, if a BGPsec speaker wishes to send a BGPsec being sent. Therefore, if a BGPsec speaker wishes to send a BGPsec
update to multiple BGP peers, it MUST generate a separate BGPsec update to multiple BGP peers, it MUST generate a separate BGPsec
update message for each unique peer AS to whom the update message is update message for each unique peer AS to whom the update message is
sent. sent.
A BGPsec update message MUST advertise a route to only a single NLRI. A BGPsec update message MUST advertise a route to only a single NLRI.
This is because a BGPsec speaker receiving an update message with This is because a BGPsec speaker receiving an update message with
multiple NLRI would be unable to construct a valid BGPsec update multiple NLRI would be unable to construct a valid BGPsec update
message (i.e., valid path signatures) containing a subset of the NLRI message (i.e., valid path signatures) containing a subset of the NLRI
in the received update. If a BGPsec speaker wishes to advertise in the received update. If a BGPsec speaker wishes to advertise
routes to multiple NLRI, then it MUST generate a separate BGPsec routes to multiple NLRI, then it MUST generate a separate BGPsec
update message for each NLRI. Additionally, a BGPsec update message update message for each NLRI. Additionally, a BGPsec update message
MUST use the MP_REACH_NLRI [3] attribute to encode the NLRI. MUST use the MP_REACH_NLRI [3] attribute to encode the NLRI.
The BGPsec_Path attribute and the AS_Path attribute are mutually
exclusive. That is, any update message containing the BGPsec_Path
attribute MUST NOT contain the AS_Path attribute. The information
that would be contained in the AS_Path attribute is instead conveyed
in the Secure_Path portion of the BGPsec_Path attribute.
In order to create or add a new signature to a BGPsec update message 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 with a given algorithm suite, the BGPsec speaker must possess a
private key suitable for generating signatures for this algorithm private key suitable for generating signatures for this algorithm
suite. Additionally, this private key must correspond to the public suite. Additionally, this private key must correspond to the public
key in a valid Resource PKI end-entity certificate whose AS number key in a valid Resource PKI end-entity certificate whose AS number
resource extension includes the BGPsec speaker's AS number [9]. Note resource extension includes the BGPsec speaker's AS number [9]. Note
also that new signatures are only added to a BGPsec update message also that new signatures are only added to a BGPsec update message
when a BGPsec speaker is generating an update message to send to an 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.
Section 4.3 contains special processing instructions for members of
an autonomous system confederation [5]. A BGPsec speaker that is not
a member of such a confederation MUST set the Flags field of the
Secure_Path Segment to zero in all BGPsec update messages it sends.
Section 4.4 contains instructions for reconstructing the AS_Path
attribute in cases where a BGPsec speaker receives an update message
with a BGPsec_Path attribute and wishes to propagate the update
message to a peer who does not support BGPsec.
4.1. Originating a New BGPsec Update
In an update message that originates a new route advertisement (i.e.,
an update whose path will contain only a single AS number), when
sending the route advertisement to an external, BGPsec-speaking peer,
the BGPsec speaker creates a new BGPsec_Path attribute as follows.
First, the BGPsec speaker constructs the Secure_Path with a single
Secure_Path Segment. The AS in this path is the BGPsec speaker's own
AS number. In particular, this AS number MUST match an AS number in
the AS number resource extension field of the Resource PKI router
certificate(s) [9] that will be used to verify the digital
signature(s) constructed by this BGPsec speaker.
The BGPsec_Path attribute and the AS_Path attribute are mutually
exclusive. That is, any update message containing the BGPsec_Path
attribute MUST NOT contain the AS_Path attribute. The information
that would be contained in the AS_Path attribute is instead conveyed
in the Secure_Path portion of the BGPsec_Path attribute.
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 [7]). It is expected that most to a given set of prefixes (see [7]). It is expected that most
relying parties will utilize BGPsec in tandem with origin validation relying parties will utilize BGPsec in tandem with origin validation
(see [19] and [20]). Therefore, it is RECOMMENDED that a BGPsec (see [19] and [20]). Therefore, it is RECOMMENDED that a BGPsec
speaker only originate a BGPsec update advertising a route for a speaker only originate a BGPsec update advertising a route for a
given prefix if there exists a valid ROA authorizing the BGPsec given prefix if there exists a valid ROA authorizing the BGPsec
speaker's AS to originate routes to this prefix. speaker's AS to originate routes to this prefix.
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.
Typically, a BGPsec speaker will use only a single algorithm suite,
and thus create only a single Signature_Block in the BGPsec_Path
attribute. However, to ensure backwards compatibility during a
period of transition from a 'current' algorithm suite to a 'new'
algorithm suite, it will be necessary to originate update messages
that contain a Signature_Block for both the 'current' and the 'new'
algorithm suites (see Section 6.1).
When originating a new route advertisement, each Signature_Block MUST
consist of a single Signature Segment. The following describes how
the BGPsec speaker populates the fields of the Signature_Block.
The Subject Key Identifier field (see Section 3) is populated with
the identifier contained in the Subject Key Identifier extension of
the RPKI router certificate corresponding to the BGPsec speaker [9].
This Subject Key Identifier will be used by recipients of the route
advertisement to identify the proper certificate to use in verifying
the signature.
The Signature field contains a digital signature that binds the NLRI
and BGPsec_Path attribute to the RPKI router certificate
corresponding to the BGPsec speaker. The digital signature is
computed as follows:
o Construct a sequence of octets by concatenating the Target AS
Number, the Secure_Path (Origin AS, pCount, and Flags), and the
Algorithm Suite Identifier. Then append to this sequence the
Address Family Identifier (AFI), Subsequent Address Family
Identifier (SAFI), and Network Layer Reachability Information
(NLRI) fields from the MP_REACH_NLRI attribute. Additionally, in
the Prefix field of the NLRI (from MP_REACH_NLRI), all of the
trailing bits MUST be set to zero when constructing this sequence.
In this sequence, the Target AS Number is the AS to whom the
BGPsec speaker intends to send the update message. (Note that the
Target AS number is the AS number announced by the peer in the
OPEN message of the BGP session within which the update is sent.)
Sequence of Octets to be Signed
+------------------------------------+
| Target AS Number (4 octets) |
+------------------------------------+
| Origin AS Number (4 octets) | ---\
+------------------------------------+ \
| pCount (1 octet) | > Secure_Path
+------------------------------------+ /
| Flags (1 octet) | ---/
+------------------------------------+
| Algorithm Suite Id. (1 octet) |
+------------------------------------+
| AFI (2 octets) | ---\
+------------------------------------+ \
| SAFI (1 octet) | > MP_REACH_NLRI
+------------------------------------+ /
| NLRI (variable) | ---/
+------------------------------------+
o Apply to this octet sequence the digest algorithm (for the
algorithm suite of this Signature_Block) to obtain a digest value.
o Apply to this digest value the signature algorithm, (for the
algorithm suite of this Signature_Block) to obtain the digital
signature. Then populate the Signature Field with this digital
signature.
The Signature Length field is populated with the length (in octets)
of the Signature field.
4.2. Propagating a Route Advertisement
When a BGPsec speaker receives a BGPsec update message containing a
BGPsec_Path attribute (with one or more signatures) from an (internal
or external) peer, it may choose to propagate the route advertisement
by sending to its (internal or external) peers by creating a new
BGPsec advertisement for the same prefix.
If a BGPsec router has received only a non-BGPsec update message If a BGPsec router has received only a non-BGPsec update message
(without the BGPsec_Path attribute), containing the AS_Path (without the BGPsec_Path attribute), containing the AS_Path
attribute, from a peer for a given prefix then it MUST NOT attach a attribute, from a peer for a given prefix then it MUST NOT attach a
BGPsec_Path attribute when it propagates the update message. (Note BGPsec_Path attribute when it propagates the update message. (Note
that a BGPsec router may also receive a non-BGPsec update message that a BGPsec router may also receive a non-BGPsec update message
from an internal peer without the AS_Path attribute, i.e., with just from an internal peer without the AS_Path attribute, i.e., with just
the NLRI in it. In that case, the prefix is originating from that AS the NLRI in it. In that case, the prefix is originating from that AS
and hence the BGPsec speaker SHOULD sign and forward the update to and hence the BGPsec speaker SHOULD sign and forward the update to
its external peers, as specified in Section 4.1.) its external BGPsec-speaking peers.)
Conversely, if a BGPsec router has received a BGPsec update message Conversely, if a BGPsec router has received a BGPsec update message
(with the BGPsec_Path attribute) from a peer for a given prefix and (with the BGPsec_Path attribute) from a peer for a given prefix and
it chooses to propagate that peer's route for the prefix, then it it chooses to propagate that peer's route for the prefix, then it
SHOULD propagate the route as a BGPsec update message containing the SHOULD propagate the route as a BGPsec update message containing the
BGPsec_Path attribute. BGPsec_Path attribute.
Note that removing BGPsec signatures (i.e., propagating a route Note that removing BGPsec signatures (i.e., propagating a route
advertisement without the BGPsec_Path attribute) has significant advertisement without the BGPsec_Path attribute) has significant
security ramifications. (See Section 7 for discussion of the security ramifications. (See Section 7 for discussion of the
security ramifications of removing BGPsec signatures.) Therefore, security ramifications of removing BGPsec signatures.) Therefore,
skipping to change at page 16, line 36 skipping to change at page 12, line 18
If the BGPsec speaker is producing an update message which would, in If the BGPsec speaker is producing an update message which would, in
the absence of BGPsec, contain an AS_SET (e.g., the BGPsec speaker is the absence of BGPsec, contain an AS_SET (e.g., the BGPsec speaker is
performing proxy aggregation), then the BGPsec speaker MUST NOT performing proxy aggregation), then the BGPsec speaker MUST NOT
include the BGPsec_Path attribute. In such a case, the BGPsec include the BGPsec_Path attribute. In such a case, the BGPsec
speaker must remove any existing BGPsec_Path in the received speaker must remove any existing BGPsec_Path in the received
advertisement(s) for this prefix and produce a traditional (non- advertisement(s) for this prefix and produce a traditional (non-
BGPsec) update message. It should be noted that BCP 172 [13] BGPsec) update message. It should be noted that BCP 172 [13]
recommends against the use of AS_SET and AS_CONFED_SET in the AS_PATH recommends against the use of AS_SET and AS_CONFED_SET in the AS_PATH
of BGP updates. of BGP updates.
The case where the BGPsec speaker sends a BGPsec update message to an
internal (iBGP) peer is quite simple. When originating a new route
advertisement and sending it to an internal peer, the BGPsec speaker
omits the BGPsec_Path attribute. When propagating a received route
advertisement to an internal peer, the BGPsec speaker typically
populates the BGPsec_Path attribute by copying the BGPsec_Path
attribute from the received update message. That is, the BGPsec_Path
attribute is copied verbatim. However, in the case that the BGPsec
speaker is performing an AS Migration, the BGPsec speaker may add an
additional signature on ingress before copying the BGPsec_Path
attribute (see [18] for more details). Note that when a BGPsec
speaker chooses to forward a BGPsec update message to an iBGP peer,
the BGPsec attribute SHOULD NOT be removed, unless the peer doesn't
support BGPsec. In particular, the BGPsec attribute SHOULD NOT be
removed even in the case where the BGPsec update message has not been
that has not successfully validated. (See Section 5 for more
information on validation, and Section 7 for the security
ramifications of removing BGPsec signatures.)
4.2. Constructing the BGPsec_Path Attribute
When a BGPsec speaker receives a BGPsec update message containing a
BGPsec_Path attribute (with one or more signatures) from an (internal
or external) peer, it may choose to propagate the route advertisement
by sending to its (internal or external) peers by creating a new
BGPsec advertisement for the same prefix. Similarly, when sending a
new route advertisement to an external, BGPsec-speaking peer, the
BGPsec speaker may send a BGPsec Update message by generating a new
BGPsec_Path attribute.
To generate the BGPsec_Path attribute on the outgoing update message, To generate the BGPsec_Path attribute on the outgoing update message,
the BGPsec speaker first prepends a new Secure_Path Segment (places the BGPsec speaker first generates a new Secure_Path Segment. Note
in first position) to the Secure_Path. The AS number in this that if the BGPsec speaker is not the origin AS and there is an
Secure_Path segment MUST match the AS number in the AS number existing BGPsec_Path attribute, then the BGPsec speaker prepends its
resource extension field of the Resource PKI router certificate(s) new Secure_Path Segment (places in first position) onto the existing
that will be used to verify the digital signature(s) constructed by Secure_Path.
this BGPsec speaker [9].
The pCount is typically set to the value 1. A BGPsec speaker may set The AS number in this Secure_Path segment MUST match the AS number in
the pCount field to a value greater than 1. (See Section 4.1 for a the AS number resource extension field of the Resource PKI router
discussion of setting pCount to a value greater than 1.) certificate(s) that will be used to verify the digital signature(s)
constructed by this BGPsec speaker [9].
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.
A route server that participates in the BGP control path, but does 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 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 to 0. This option enables the route server to participate in BGPsec
and obtain the associated security guarantees without increasing the and obtain the associated security guarantees without increasing the
effective length of the AS path. (Note that BGPsec speakers compute 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 effective length of the AS path by summing the pCount values in
the BGPsec_Path attribute, see Section 5.) However, when a route the BGPsec_Path attribute, see Section 5.) However, when a route
server sets the pCount value to 0, it still inserts its AS number server sets the pCount value to 0, it still inserts its AS number
into the Secure_Path segment, as this information is needed to into the Secure_Path segment, as this information is needed to
validate the signature added by the route server. (See [18] for a validate the signature added by the route server. (See [18] for a
discussion of setting pCount to 0 to facilitate AS Number Migration.) discussion of setting pCount to 0 to facilitate AS Number Migration.)
BGPsec speakers SHOULD drop incoming update messages with pCount set BGPsec speakers SHOULD drop incoming update messages with pCount set
to zero in cases where the BGPsec speaker does not expect its peer to to zero in cases where the BGPsec speaker does not expect its peer to
set pCount to zero. (That is, pCount is only to be set to zero in set pCount to zero. (That is, pCount is only to be set to zero in
cases such as route servers or AS Number Migration where the BGPsec cases such as route servers or AS Number Migration where the BGPsec
speaker's peer expects pCount to be set to zero.) speaker's peer expects pCount to be set to zero.)
Next, the BGPsec speaker generates one or two Signature_Blocks.
Typically, a BGPsec speaker will use only a single algorithm suite,
and thus create only a single Signature_Block in the BGPsec_Path
attribute. However, to ensure backwards compatibility during a
period of transition from a 'current' algorithm suite to a 'new'
algorithm suite, it will be necessary to originate update messages
that contain a Signature_Block for both the 'current' and the 'new'
algorithm suites (see Section 6.1).
If the received BGPsec update message contains two Signature_ Blocks If the received BGPsec update message contains two Signature_ Blocks
and the BGPsec speaker supports both of the corresponding algorithms and the BGPsec speaker supports both of the corresponding algorithms
suites, then the new update message generated by the BGPsec speaker suites, then the new update message generated by the BGPsec speaker
SHOULD include both of the Signature_Blocks. If the received BGPsec SHOULD include both of the Signature_Blocks. If the received BGPsec
update message contains two Signature_Blocks and the BGPsec speaker update message contains two Signature_Blocks and the BGPsec speaker
only supports one of the two corresponding algorithm suites, then the only supports one of the two corresponding algorithm suites, then the
BGPsec speaker MUST remove the Signature_Block corresponding to the BGPsec speaker MUST remove the Signature_Block corresponding to the
algorithm suite that it does not understand. If the BGPsec speaker algorithm suite that it does not understand. If the BGPsec speaker
does not support the algorithm suites in any of the Signature_Blocks does not support the algorithm suites in any of the Signature_Blocks
contained in the received update message, then the BGPsec speaker contained in the received update message, then the BGPsec speaker
skipping to change at page 18, line 6 skipping to change at page 14, line 37
BGPsec speaker does support, the BGPsec speaker adds a new Signature BGPsec speaker does support, the BGPsec speaker adds a new Signature
Segment to the Signature_Block. This Signature Segment is prepended Segment to the Signature_Block. This Signature Segment is prepended
to the list of Signature Segments (placed in the first position) so to the list of Signature Segments (placed in the first position) so
that the list of Signature Segments appear in the same order as the that the list of Signature Segments appear in the same order as the
corresponding Secure_Path segments. The BGPsec speaker populates the corresponding Secure_Path segments. The BGPsec speaker populates the
fields of this new signature segment as follows. fields of this new signature segment as follows.
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 router certificate corresponding to the BGPsec speaker [9]. the RPKI router certificate corresponding to the BGPsec speaker [9].
This Subject Key Identifier will be used by recipients of the route
This 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 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 and BGPsec_Path attribute to the RPKI router that binds the NLRI and BGPsec_Path attribute to the RPKI router
certificate corresponding to the BGPsec speaker. The digital certificate corresponding to the BGPsec speaker. The digital
signature is computed as follows: signature is computed as follows:
o Construct a sequence of octets by concatenating the Target AS o Construct a sequence of octets by concatenating the Target AS
number, the Secure_Path segment that is being added by the BGPsec Number, and the newly-created Secure_Path Segment (Origin AS,
speaker constructing the signature, and the signature field of the pCount, and Flags). Note that the Target AS Number is the AS
most recent Signature Segment (the one corresponding to AS from Number of the BGPsec peer to whom the newly-created Update message
whom the BGPsec speaker's AS received the announcement). Note is being sent. Then (if the BGPsec speaker is not the origin AS)
that the Target AS number is the AS number announced by the peer append to this sequence previous Secure_Path and the previous
in the OPEN message of the BGP session within which the BGPsec Signature_Block that were present on the received Update message.
update message is sent. Finally, append the Address Family Identifier (AFI), Subsequent
Address Family Identifier (SAFI), and Network Layer Reachability
Information (NLRI) fields from the MP_REACH_NLRI attribute.
Additionally, in the Prefix field of the NLRI (from
MP_REACH_NLRI), all of the trailing bits MUST be set to zero when
constructing this sequence. In this sequence, the Target AS Number
is the AS to whom the BGPsec speaker intends to send the update
message. (Note that the Target AS number is the AS number
announced by the peer in the OPEN message of the BGP session
within which the update is sent.)
Sequence of Octets to be Signed Sequence of Octets to be Signed
+--------------------------------------+ +-------------------------------------+
| Target AS Number (4 octets) | | Target AS Number (4 octets) |
+--------------------------------------+ +-------------------------------------+
| Signer's AS Number (4 octets) | ---\ | AS Number (4 octets) |
+--------------------------------------+ \ +-------------------------------------+
| pCount (1 octet) | > Secure_Path | pCount (1 octet) |
+--------- ----------------------------+ / +-------------------------------------+
| Flags (1 octet) | ---/ | Flags (1 octet) |
+--------------------------------------+ +-------------------------------------+
| Most Recent Sig Field (variable) | | Previous Secure_Path (variable) |
+--------------------------------------+ +-------------------------------------+
| Previous Signature_Block (variable) |
+-------------------------------------+
| AFI (2 octets) | ---\
+-------------------------------------+ \
| SAFI (1 octet) | > MP_REACH_NLRI
+-------------------------------------+ /
| NLRI (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_Block) to obtain a digest value. algorithm suite of this Signature_Block) 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_Block) to obtain the digital algorithm suite of this Signature_Block) to obtain the digital
signature. Then populate the Signature Field with this digital signature. Then populate the Signature Field with this digital
signature. signature.
The Signature Length field is populated with the length (in octets) The Signature Length field is populated with the length (in octets)
skipping to change at page 19, line 31 skipping to change at page 16, line 26
whenever, in a non-BGPsec update message, the AS number would appear whenever, in a non-BGPsec update message, the AS number would appear
in a segment of type AS_CONFED_SEQUENCE in a non-BGPsec update in a segment of type AS_CONFED_SEQUENCE in a non-BGPsec update
message. message.
Within a confederation, the verification of BGPsec signatures added Within a confederation, the verification of BGPsec signatures added
by other members of the confederation is optional. If a by other members of the confederation is optional. If a
confederation chooses not to have its members verify signatures added confederation chooses not to have its members verify signatures added
by other confederation members, then when sending a BGPsec update by other confederation members, then when sending a BGPsec update
message to a peer that is a member of the same confederation, the message to a peer that is a member of the same confederation, the
confederation members MAY set the Signature field within the confederation members MAY set the Signature field within the
Signature_Segment that it generates to be zero (in lieu of Signature Segment that it generates to be zero (in lieu of
calculating the correct digital signature as described in Sections calculating the correct digital signature as described in Sections
4.1 and 4.2). Note that if a confederation chooses not to verify 4.1 and 4.2). Note that if a confederation chooses not to verify
digital signatures within the confederation, then BGPsec is able to digital signatures within the confederation, then BGPsec is able to
provide no assurances about the integrity of the (private) Member-AS provide no assurances about the integrity of the (private) Member-AS
Numbers placed in Secure_Path segments where the Confed_Segment flag Numbers placed in Secure_Path segments where the Confed_Segment flag
is set to one. is set to one.
When a confederation member receives a BGPsec update message from a When a confederation member receives a BGPsec update message from a
peer within the confederation and propagates it to a peer outside the peer within the confederation and propagates it to a peer outside the
confederation, it needs to remove all of the Secure_Path Segments confederation, it needs to remove all of the Secure_Path Segments
added by confederation members as well as the corresponding Signature added by confederation members as well as the corresponding Signature
Segments. To do this, the confederation member propagating the route Segments. To do this, the confederation member propagating the route
outside the confederation does the following: outside the confederation does the following:
o First, starting with the most recently added Secure_Path segment, o First, starting with the most recently added Secure_Path segment,
remove all of the consecutive Secure_Path segments that have the remove all of the consecutive Secure_Path segments that have the
Confed_Segment flag set to one. Stop this process once a Confed_Segment flag set to one. Stop this process once a
Scure_Path segment is reached which has its Confed_Segment flag Secure_Path segment is reached which has its Confed_Segment flag
set to zero. Keep a count of the number of segments removed in set to zero. Keep a count of the number of segments removed in
this fashion. this fashion.
o Second, starting with the most recently added Signature Segment, o Second, starting with the most recently added Signature Segment,
remove a number of Signature Segments equal to the number of remove a number of Signature Segments equal to the number of
Secure_Path Segments removed in the previous step. (That is, Secure_Path Segments removed in the previous step. (That is,
remove the K most recently added signature segments, where K is remove the K most recently added signature segments, where K is
the number of Secure_Path Segments removed in the previous step.) the number of Secure_Path Segments removed in the previous step.)
o Finally, add a Secure_Path Segment containing, in the AS field, o Finally, add a Secure_Path Segment containing, in the AS field,
skipping to change at page 20, line 44 skipping to change at page 17, line 40
(Note that the algorithm in Section 5.2 processes Secure_Path (Note that the algorithm in Section 5.2 processes Secure_Path
Segments in order from most recently added to least recently added, Segments in order from most recently added to least recently added,
therefore this special case will apply to the first Secure_Path therefore this special case will apply to the first Secure_Path
segment that the algorithm encounters that has the Confed_Segment segment that the algorithm encounters that has the Confed_Segment
flag set to zero.) flag set to zero.)
Finally, as discussed above, an AS confederation may optionally Finally, as discussed above, an AS confederation may optionally
decide that its members will not verify digital signatures added by decide that its members will not verify digital signatures added by
members. In such a federation, when a confederation member runs the members. In such a federation, when a confederation member runs the
algorithm in Section 5.2, the confederation member, during processing algorithm in Section 5.2, the confederation member, during processing
of a Signature_Segment, first checks whether the Confed_Sequence flag of a Signature Segment, first checks whether the Confed_Sequence flag
in the corresponding Secure_Path segment is set to one. If the in the corresponding Secure_Path segment is set to one. If the
Confed_Sequence flag is set to one in the corresponding Secure_Path Confed_Sequence flag is set to one in the corresponding Secure_Path
segment, the confederation member does not perform any further checks segment, the confederation member does not perform any further checks
on the Signature_Segment and immediately moves on to the next on the Signature Segment and immediately moves on to the next
Signature_Segment (and checks its corresponding Secure_Path segment). Signature Segment (and checks its corresponding Secure_Path segment).
Note that as specified in Section 5.2, it is an error when a BGPsec Note that as specified in Section 5.2, it is an error when a BGPsec
speaker receives from a peer, who is not in the same AS speaker receives from a peer, who is not in the same AS
confederation, a BGPsec update containing a Confed_Sequence flag set confederation, a BGPsec update containing a Confed_Sequence flag set
to one. (As discussed in Section 5.2, any error in the BGPsec_Path to one. (As discussed in Section 5.2, any error in the BGPsec_Path
attribute MUST be handled using the "treat-as-withdraw", approach as attribute MUST be handled using the "treat-as-withdraw", approach as
defined in RFC WXYZ [11].) defined in RFC WXYZ [11].)
4.4. Reconstructing the AS_PATH Attribute 4.4. Reconstructing the AS_PATH Attribute
BGPsec update messages do not contain the AS_PATH attribute. However, BGPsec update messages do not contain the AS_PATH attribute. However,
skipping to change at page 27, line 33 skipping to change at page 23, line 27
RPKI router certificate data and look up all valid (AS, SKI, RPKI router certificate data and look up all valid (AS, SKI,
Public Key) triples in which the AS matches the AS number in the Public Key) triples in which the AS matches the AS number in the
corresponding Secure_Path segment. Of these triples that match corresponding Secure_Path segment. Of these triples that match
the AS number, check whether there is an SKI that matches the the AS number, check whether there is an SKI that matches the
value in the Subject Key Identifier field of the Signature value in the Subject Key Identifier field of the Signature
segment. If this check finds no such matching SKI value, then segment. If this check finds no such matching SKI value, then
mark the entire Signature_Block as 'Not Valid' and proceed to the mark the entire Signature_Block as 'Not Valid' and proceed to the
next Signature_Block. next Signature_Block.
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.
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
+-------------------------------------------+ Sequence of Octets to be Hashed
| AS Number of Target AS (4 octets) | +-------------------------------------+
+-------------------------------------------+ | AS Number of Target (4 octets) |
| AS Number (4 octets) | ---\ +-------------------------------------+
+-------------------------------------------+ \ | AS Number (4 octets) |
| pCount (1 octet) | > Secure_Path +-------------------------------------+
+-------------------------------------------+ / | pCount (1 octet) |
| Flags (1 octet) | ---/ +-------------------------------------+
+-------------------------------------------+ | Flags (1 octet) |
| Sig Field in the Next Segment (variable) | +-------------------------------------+
+-------------------------------------------+ | Rest of Secure_Path (variable) |
+-------------------------------------+
| Rest of Signature_Block (variable) |
+-------------------------------------+
| AFI (2 octets) | ---\
+-------------------------------------+ \
| SAFI (1 octet) | > MP_REACH_NLRI
+-------------------------------------+ /
| NLRI (variable) | ---/
+-------------------------------------+
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 Target AS' is the AS number of the BGPsec segment), the 'AS Number of Target AS' is the AS number of the BGPsec
speaker validating the update message. Note that if a BGPsec speaker speaker validating the update message. Note that if a BGPsec speaker
uses multiple AS Numbers (e.g., the BGPsec speaker is a member of a uses multiple AS Numbers (e.g., the BGPsec speaker is a member of a
confederation), the AS number used here MUST be the AS number confederation), the AS number used here MUST be the AS number
announced in the OPEN message for the BGP session over which the announced in the OPEN message for the BGP session over which the
BGPsec update was received. BGPsec update was received.
For each other Signature Segment, the 'AS Number of Target AS' is the For each other Signature Segment, the 'AS Number of Target AS' is the
AS number in the Secure_Path segment that corresponds to the AS number in the Secure_Path segment that corresponds to the
Signature Segment added immediately after the one being processed. Signature Segment added immediately after the one being processed.
(That is, in the Secure_Path segment that corresponds to the (That is, in the Secure_Path segment that corresponds to the
Signature segment that the validator just finished processing.) Signature segment that the validator just finished processing.)
The AS Number, pCount and Flags fields are taken from the Secure_Path The AS Number, pCount and Flags fields are taken from the Secure_Path
segment that corresponds to the Signature segment currently being segment that corresponds to the Signature segment currently being
processed. The 'Signature Field in the Next Segment' is the processed. The 'Rest of Secure_Path' is obtained by removing from
Signature field found in the Signature segment that is next to be the Secure_Path the segment that is currently being processes. That
processed (that is, the next most recently added Signature Segment). is, 'Rest of Secure_Path' is what the Secure_Path would have
contained before the currently processed segment was added.
Alternatively, if the segment being processed corresponds to the Similarly, the 'Rest of Signature_Block' is obtained by removing from
origin AS (i.e., if it is the least recently added segment), then the the Signature_Block the Signature Segment corresponding to the
digest function should be computed on the following sequence of current Secure_Path Segment. That is, 'Rest of Signature_Block' is
octets: what the Signature_Block would have contained before the currently
processed segment was added.
Sequence of Octets to be Hashed
+------------------------------------+
| AS Number of Target AS (4 octets) |
+------------------------------------+
| Origin AS Number (4 octets) | ---\
+------------------------------------+ \
| pCount (1 octet) | > Secure_Path
+------------------------------------+ /
| Flags (1 octet) | ---/
+------------------------------------+
| Algorithm Suite Id. (1 octet) |
+------------------------------------+
| AFI (2 octets) | ---\
+------------------------------------+ \
| SAFI (1 octet) | > MP_REACH_NLRI
+------------------------------------+ /
| NLRI (variable) | ---/
+------------------------------------+
The Address Family Identifier (AFI), Subsequent Address Family The Address Family Identifier (AFI), Subsequent Address Family
Identifier (SAFI), and Network Layer Reachability Information (NLRI) Identifier (SAFI), and Network Layer Reachability Information (NLRI)
are obtained directly from the MP_REACH_NLRI attribute of the update are obtained directly from the MP_REACH_NLRI attribute of the update
message. However, in the Prefix field of the NLRI (from message. However, in the Prefix field of the NLRI (from
MP_REACH_NLRI), all of the trailing bits MUST be set to zero for the MP_REACH_NLRI), all of the trailing bits MUST be set to zero for the
purpose of signature verification. The Algorithm Suite Identifier is purpose of signature verification.
obtained from the BGPsec_Path attribute being validated. The Origin
AS Number, pCount, and Flags fields are taken from the Secure_Path
segment corresponding to the Signature Segment currently being
processed.
The 'AS Number of Target AS' is the AS Number from the Secure_Path
segment that was added immediately after the Secure_Path segment
containing the Origin AS Number. (That is, the Secure_Path segment
corresponding to the Signature segment that the receiver just
finished processing prior to the current Signature segment.)
o (Step III): Use the signature validation algorithm (for the given o (Step III): Use the signature validation algorithm (for the given
algorithm suite) to verify the signature in the current segment. algorithm suite) to verify the signature in the current segment.
That is, invoke the signature validation algorithm on the That is, invoke the signature validation algorithm on the
following three inputs: the value of the Signature field in the following three inputs: the value of the Signature field in the
current segment; the digest value computed in Step II above; and current segment; the digest value computed in Step II above; and
the public key obtained from the valid RPKI data in Step I above. the public key obtained from the valid RPKI data in Step I above.
If the signature validation algorithm determines that the If the signature validation algorithm determines that the
signature is invalid, then mark the entire Signature_Block as 'Not signature is invalid, then mark the entire Signature_Block as 'Not
Valid' and proceed to the next Signature_Block. If the signature Valid' and proceed to the next Signature_Block. If the signature
skipping to change at page 37, line 27 skipping to change at page 31, line 20
Randy Bush Randy Bush
Internet Initiative Japan Internet Initiative Japan
randy@psg.com randy@psg.com
Russ Housley Russ Housley
Vigil Security Vigil Security
housley@vigilsec.com housley@vigilsec.com
Matt Lepinski Matt Lepinski
New College of Florida New College of Florida
mlepinski.ietf@gmail.com mlepinski@ncf.edu
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
skipping to change at page 37, line 52 skipping to change at page 31, line 45
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
Parsons Parsons
weiler+ietf@watson.org weiler+ietf@watson.org
9.2. Acknowledgements 9.2. Acknowledgements
The authors would like to thank Michael Baer, Luke Berndt, Sharon The authors would like to thank Michael Baer, Luke Berndt, Sharon
Goldberg, Ed Kern, Chris Morrow, Doug Maughan, Pradosh Mohapatra, Goldberg, Ed Kern, David Mandelberg, Doug Maughan, Pradosh Mohapatra,
Russ Mundy, Sandy Murphy, Keyur Patel, Mark Reynolds, Heather Chris Morrow, Russ Mundy, Sandy Murphy, Keyur Patel, Mark Reynolds,
Schiller, Jason Schiller, John Scudder, Ruediger Volk and David Ward Heather Schiller, Jason Schiller, John Scudder, Ruediger Volk and
for their valuable input and review. David Ward for their valuable input and review.
10. Normative References 10. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] 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.
[2] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border [2] 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.
[3] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [3] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
skipping to change at page 39, line 37 skipping to change at page 34, line 8
Using the Resource Certificate Public Key Infrastructure (PKI) Using the Resource Certificate Public Key Infrastructure (PKI)
and Route Origin Authorizations (ROAs)", RFC 6483, February and Route Origin Authorizations (ROAs)", RFC 6483, February
2013. 2013.
[20] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, [20] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein,
"BGP Prefix Origin Validation", RFC 6811, January 2013. "BGP Prefix Origin Validation", RFC 6811, January 2013.
Author's Address Author's Address
Matthew Lepinski (editor) Matthew Lepinski (editor)
BBN Technologies New College of Florida
10 Moulton St 5800 Bay Shore Road
Cambridge, MA 55409 Sarasota, FL 34243
US US
Phone: +1 617 873 5939 Phone: +1 941 487 5000
Email: mlepinski.ietf@gmail.com Email: mlepinski@ncf.edu
 End of changes. 31 change blocks. 
270 lines changed or deleted 190 lines changed or added

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