draft-ietf-sidr-bgpsec-threats-01.txt   draft-ietf-sidr-bgpsec-threats-02.txt 
Secure Inter-Domain Routing S. Kent Secure Inter-Domain Routing S. Kent
Internet-Draft A. Chi Internet-Draft A. Chi
Intended status: Standards Track BBN Intended status: Standards Track BBN
Expires: August 6, 2012 February 3, 2012 Expires: August 25, 2012 February 22, 2012
Threat Model for BGP Path Security Threat Model for BGP Path Security
draft-ietf-sidr-bgpsec-threats-01 draft-ietf-sidr-bgpsec-threats-02
Abstract Abstract
This document describes a threat model for BGP path security This document describes a threat model for BGP path security
(BGPSEC). It assumes the context established by the SIDR WG charter, (BGPSEC). It assumes the context established by the SIDR WG charter,
as of April 19, 2011. The charter established two goals for the SIDR as of April 19, 2011. The charter established two goals for the SIDR
work: work:
o Enabling an AS to verify the authorization of an origin AS to o Enabling an AS to verify the authorization of an origin AS to
originate a specified set of prefixes originate a specified set of prefixes
skipping to change at page 2, line 6 skipping to change at page 2, line 6
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 August 6, 2012. This Internet-Draft will expire on August 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 3, line 24 skipping to change at page 3, line 24
(non-CA computers) . . . . . . . . . . . . . . . . . . . . 13 (non-CA computers) . . . . . . . . . . . . . . . . . . . . 13
4.4. Attacks on a repository publication point . . . . . . . . 14 4.4. Attacks on a repository publication point . . . . . . . . 14
4.5. Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . 16 4.5. Attacks on an RPKI CA . . . . . . . . . . . . . . . . . . 16
5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . . 19 5. Residual Vulnerabilities . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
This document describes the security context in which BGPSEC is This document describes the security context in which BGPSEC is
intended to operate. It discusses classes of potential adversaries intended to operate. It discusses classes of potential adversaries
that are considered to be threats, and classes of attacks that might that are considered to be threats, and classes of attacks that might
be launched against BGPSEC. Because BGPSEC depends on the Resource be launched against BGPSEC. Because BGPSEC depends on the Resource
Public Key Infrastructure (RPKI) [I-D.ietf-sidr-arch], threats and Public Key Infrastructure (RPKI) [RFC6480], threats and attacks
attacks against the RPKI are included. This model also takes into against the RPKI are included. This model also takes into
consideration classes of attacks that are enabled by the use of consideration classes of attacks that are enabled by the use of
BGPSEC (based on the current BGPSEC design.) BGPSEC (based on the current BGPSEC design.)
The motivation for developing BGPSEC, i.e., residual security The motivation for developing BGPSEC, i.e., residual security
concerns for BGP, is well described in several documents, including concerns for BGP, is well described in several documents, including
"BGP Security Vulnerabilities Analysis" [RFC4272] and "Design and "BGP Security Vulnerabilities Analysis" [RFC4272] and "Design and
Analysis of the Secure Border Gateway Protocol (S-BGP)" [Kent2000]. Analysis of the Secure Border Gateway Protocol (S-BGP)" [Kent2000].
All of these papers note that BGP does not include mechanisms that All of these papers note that BGP does not include mechanisms that
allow an Autonomous System (AS) to verify the legitimacy and allow an Autonomous System (AS) to verify the legitimacy and
authenticity of BGP route advertisements. (BGP now mandates support authenticity of BGP route advertisements. (BGP now mandates support
skipping to change at page 4, line 51 skipping to change at page 4, line 51
information arising from a legitimate peer. The risk of information arising from a legitimate peer. The risk of
disruptions caused by legitimate BGP speakers is real and cannot disruptions caused by legitimate BGP speakers is real and cannot
be ignored. be ignored.
BGPSEC is intended to address the concerns cited above, to provide BGPSEC is intended to address the concerns cited above, to provide
significantly improved path security, building upon the secure route significantly improved path security, building upon the secure route
origination foundation offered by use of the RPKI. Specifically, the origination foundation offered by use of the RPKI. Specifically, the
RPKI enables relying parties (RPs) to determine if the origin AS for RPKI enables relying parties (RPs) to determine if the origin AS for
a path was authorized to advertise the prefix contained in a BGP a path was authorized to advertise the prefix contained in a BGP
update message. This security feature is enabled by the use of two update message. This security feature is enabled by the use of two
types of digitally signed data: a PKI [I-D.ietf-sidr-res-certs] that types of digitally signed data: a PKI [RFC6487] that associates one
associates one or more prefixes with the public key(s) of an address or more prefixes with the public key(s) of an address space holder,
space holder, and Route Origination Authorizations (ROAs) and Route Origination Authorizations (ROAs) [RFC6482] that allows a
[I-D.ietf-sidr-roa-format] that allows a prefix holder to specify the prefix holder to specify the AS(es) that are authorized to originate
AS(es) that are authorized to originate routes for a prefix. routes for a prefix.
The security model adopted for BGPSEC does not assume an "oracle" The security model adopted for BGPSEC does not assume an "oracle"
that can see all of the BGP inputs and outputs associated with every that can see all of the BGP inputs and outputs associated with every
AS or every BGP router. Instead, the model is based on a local AS or every BGP router. Instead, the model is based on a local
notion of what constitutes legitimate, authorized behavior by the BGP notion of what constitutes legitimate, authorized behavior by the BGP
routers associated with an AS. This is an AS-centric model of secure routers associated with an AS. This is an AS-centric model of secure
operation, consistent with the AS-centric model that BGP employs for operation, consistent with the AS-centric model that BGP employs for
routing. This model forms the basis for the discussion that follows. routing. This model forms the basis for the discussion that follows.
This document begins with a brief set of definitions relevant to the This document begins with a brief set of definitions relevant to the
skipping to change at page 7, line 43 skipping to change at page 7, line 43
RPKI Repository System - The RPKI repository system consists of a RPKI Repository System - The RPKI repository system consists of a
distributed set of loosely synchronized databases. distributed set of loosely synchronized databases.
Resource PKI (RPKI) - A PKI operated by the entities that manage Resource PKI (RPKI) - A PKI operated by the entities that manage
INRs, and that issues X509 certificates (and CRLs) that attest to the INRs, and that issues X509 certificates (and CRLs) that attest to the
holdings of INRs. holdings of INRs.
RPKI Signed Object - An RPKI signed object is a Cryptographic Message RPKI Signed Object - An RPKI signed object is a Cryptographic Message
Syntax (CMS)-encapsulated data object complying with the format and Syntax (CMS)-encapsulated data object complying with the format and
semantics defined in [I-D.ietf-sidr-signed-object]. semantics defined in [RFC6488].
Route - In the Internet, a route is a prefix and an associated Route - In the Internet, a route is a prefix and an associated
sequence of ASNs that indicates a path via which traffic destined for sequence of ASNs that indicates a path via which traffic destined for
the prefix can be directed. (The route includes the origin AS.) the prefix can be directed. (The route includes the origin AS.)
Route leak - A route leak is said to occur when AS-A advertises Route leak - A route leak is said to occur when AS-A advertises
routes that it has received from an AS-B to AS-A's neighbors, but routes that it has received from an AS-B to AS-A's neighbors, but
AS-A is not viewed as a transit provider for the prefixes in the AS-A is not viewed as a transit provider for the prefixes in the
route. route.
skipping to change at page 12, line 43 skipping to change at page 12, line 43
by an earlier AS, prior to being released. Thus only an immediate by an earlier AS, prior to being released. Thus only an immediate
neighbor of a route originator could be expected to detect this neighbor of a route originator could be expected to detect this
type of attack. type of attack.
MITM Attack: A cryptographic key used for point-to-point security MITM Attack: A cryptographic key used for point-to-point security
(e.g., TCP-AO, TLS, or IPsec) between two BGP routers might be (e.g., TCP-AO, TLS, or IPsec) between two BGP routers might be
compromised (e.g., by extraction from a router). This would compromised (e.g., by extraction from a router). This would
enable an adversary to effect MITM attacks on the link(s) where enable an adversary to effect MITM attacks on the link(s) where
the key is used. Use of specific security mechanisms to protect the key is used. Use of specific security mechanisms to protect
inter-router links between ASes is outside the scope of BGPSEC. inter-router links between ASes is outside the scope of BGPSEC.
However, XXX
Compromised Router Private Key: The private key associated with an Compromised Router Private Key: The private key associated with an
RPKI EE certificate issued to a router might be compromised by an RPKI EE certificate issued to a router might be compromised by an
attack against the router. An adversary with access to this key attack against the router. An adversary with access to this key
would be able to generate updates that appear to be from this would be able to generate updates that appear to have passed
router (or from any routers that share this key and certificate). through the AS that this router represents. Such updates might be
If the adversary controlled another network operator, it could use in injected on a link between the compromised router and its
this key to forge signatures that appear to come from the neighbors, if that link is accessible to the adversary. If the
router(s) in question, thus making it appear that those routers adversary controls another network, it could use this key to forge
were misbehaving. signatures that appear to come from the AS or router(s) in
question, with some contraints. So, for example, an adversary
that controls another AS could use a compromised router key to
issue signed routes that include the targeted AS/router, with
limits. (Neighbors of the adversary's AS ought not accept a route
that purports to emanate directly from the targeted AS. So, an
adversary can take a legitimate route that passes through the
compromised AS, add itself as the next hop, and then forward the
resulting route to neighbors.)
Replay Attack: A BGPSEC-protected update may be signed and Replay Attack: A BGPSEC-protected update may be signed and
announced, and later withdrawn. An adversary controlling announced, and later withdrawn. An adversary controlling
intermediate routers could fail to propagate the withdrawal, and intermediate routers could fail to propagate the withdrawal, and
instead re-announce (i.e., replay) a previous announcement (that instead re-announce (i.e., replay) a previous announcement (that
has not yet expired). BGP is already vulnerable to behavior of has not yet expired). BGP is already vulnerable to behavior of
this sort; re-announcement cannot be characterized as an attack, this sort; re-announcement cannot be characterized as an attack,
under the assumptions upon which this mode is based (i.e., no under the assumptions upon which this mode is based (i.e., no
oracle). oracle).
skipping to change at page 15, line 32 skipping to change at page 15, line 39
If an adversary deletes a manifest (and does not replace it with an If an adversary deletes a manifest (and does not replace it with an
older instance), that is detectable by RPs. Such behavior should older instance), that is detectable by RPs. Such behavior should
result in the CA (or publication point maintainer) being notified of result in the CA (or publication point maintainer) being notified of
the problem. An RP can continue to use the last valid instance of the problem. An RP can continue to use the last valid instance of
the deleted manifest (a local policy option), thus minimizing the the deleted manifest (a local policy option), thus minimizing the
impact of such an attack. impact of such an attack.
If an adversary deletes newly added CA certificates or ROAs, and If an adversary deletes newly added CA certificates or ROAs, and
replaces the current manifest with the previous manifest, the replaces the current manifest with the previous manifest, the
manifest (and the CRL that it matches) will be "stale" (see manifest (and the CRL that it matches) will be "stale" (see
[I-D.ietf-sidr-rpki-manifests]). This alerts an RP that there may be [RFC6486]). This alerts an RP that there may be a problem, and,
a problem, and, hopefully, the entity responsible for the publication hopefully, the entity responsible for the publication point will be
point will be asked to remedy the problem (e.g., republish the asked to remedy the problem (e.g., republish the missing CA
missing CA certificates and/or ROAs). An RP cannot know the content certificates and/or ROAs). An RP cannot know the content of the new
of the new certificates or ROAs that are not present, but it can certificates or ROAs that are not present, but it can continue to use
continue to use what it has cached. An attack of this sort will, at what it has cached. An attack of this sort will, at least
least temporarily, cause RPs to be un aware of the newly published temporarily, cause RPs to be un aware of the newly published objects.
objects. INRs associated with these objects will be treated as INRs associated with these objects will be treated as
unauthenticated. unauthenticated.
If a CA revokes a CA certificate or a ROA (via deleting the If a CA revokes a CA certificate or a ROA (via deleting the
corresponding EE certificate), and the adversary tries to reinstate corresponding EE certificate), and the adversary tries to reinstate
that CA certificate or ROA, the adversary would have to rollback the that CA certificate or ROA, the adversary would have to rollback the
CRL and the manifest to undo this action by the CA. As above, this CRL and the manifest to undo this action by the CA. As above, this
would make the CRL and manifest stale, and this is detectable by RPs. would make the CRL and manifest stale, and this is detectable by RPs.
An RP cannot know which CA certificates or ROAs were deleted. An RP cannot know which CA certificates or ROAs were deleted.
Depending on local policy, the RP might use the cached instances of Depending on local policy, the RP might use the cached instances of
the affected objects, and thus be tricked into making decisions based the affected objects, and thus be tricked into making decisions based
skipping to change at page 19, line 15 skipping to change at page 19, line 15
5. Residual Vulnerabilities 5. Residual Vulnerabilities
The RPKI, upon which BGPSEC relies, has several residual The RPKI, upon which BGPSEC relies, has several residual
vulnerabilities that were discussed in the preceding text vulnerabilities that were discussed in the preceding text
(Section 4.4 and Section 4.5). These vulnerabilities are of two (Section 4.4 and Section 4.5). These vulnerabilities are of two
principle forms: principle forms:
o the RPKI repository system may be attacked in ways that make its o the RPKI repository system may be attacked in ways that make its
contents unavailable, not current, or inconsistent. The principle contents unavailable, not current, or inconsistent. The principle
defense against most forms of DoS attacks is the use of a local defense against most forms of DoS attacks is the use of a local
cache by RPs. The local cache ensures availability of previously- cache by each RP. The local cache ensures availability of
acquired RPKI data, in the event that a repository is inaccessible previously-acquired RPKI data, in the event that a repository is
or if repository contents are deleted (maliciously). Nonetheless, inaccessible or if repository contents are deleted (maliciously).
the system cannot ensure that every RP will always have access to Nonetheless, the system cannot ensure that every RP will always
up-to-date RPKI data. An RP, when it detects a problem with have access to up-to-date RPKI data. An RP, when it detects a
acquired repository data has two options: problem with acquired repository data has two options:
1. The RP may choose to make use of its local cache, employing 1. The RP may choose to make use of its local cache, employing
local configuration settings that tolerate expired or stale local configuration settings that tolerate expired or stale
objects. (Such behavior is, nominally, always within the objects. (Such behavior is, nominally, always within the
purview of an RP in PKI.) Using cached, expired or stale data purview of an RP in PKI.) Using cached, expired or stale data
subjects the RP to attacks that take advantage of the RP's subjects the RP to attacks that take advantage of the RP's
ignorance of changes to this data. ignorance of changes to this data.
2. The RP may chose to purge expired objects. Purging expired 2. The RP may chose to purge expired objects. Purging expired
objects removes the security info associated with the real objects removes the security info associated with the real
skipping to change at page 19, line 50 skipping to change at page 19, line 50
o any CA in the RPKI may misbehave within the bounds of the INRs o any CA in the RPKI may misbehave within the bounds of the INRs
allocated to it, e.g., it may issue certificates with duplicate allocated to it, e.g., it may issue certificates with duplicate
resource allocations or revoke certificates inappropriately. This resource allocations or revoke certificates inappropriately. This
vulnerability is intrinsic in any PKI, but its impact is limited vulnerability is intrinsic in any PKI, but its impact is limited
in the RPKI because of the use or RFC 3779 extensions. It is in the RPKI because of the use or RFC 3779 extensions. It is
anticipated that RPs will deal with such misbehavior through anticipated that RPs will deal with such misbehavior through
administrative means, once it is detected. administrative means, once it is detected.
BGPSEC has a separate set of residual vulnerabilities: BGPSEC has a separate set of residual vulnerabilities:
o BGPSEC is not able to prevent what is usually referred to as route o "Route leaks" are viewed as a routing security problem by many
leaks, because BGP itself does not distinguish between transit and network operators, even though there is no IETF-codified
non-transit ASes. It might be possible to address this definition of a route leak. BGP itself does not include semantics
vulnerability if every AS were required to publish its status as a that preclude what many perceive as route leaks. Moreover, route
transit or non-transit AS, relative to its peers. However, route leaks are outside the scope of BGPSEC, at this time, based on the
leaks are outside the scope of the SIDR charter at the time this SIDR charter. Thus route leaks are not addressed in this threat
document was prepared. model.
o BGPSEC signatures do not protect all attributes associated with an o BGPSEC signatures do not protect all attributes associated with an
AS_path. Some of these attributes are employed as inputs to AS_path. Some of these attributes are employed as inputs to
routing decisions. Thus attacks that modify (or strip) these routing decisions. Thus attacks that modify (or strip) these
other attributes are not detected by BGPSEC. The SIDR charter other attributes are not detected by BGPSEC. The SIDR charter
calls for protecting only the info needed to verify that a calls for protecting only the info needed to verify that a
received route traversed the ASes on question, and that the NLRI received route traversed the ASes on question, and that the NLRI
in the route is what was advertised. Thus, protection of other in the route is what was advertised. Thus, protection of other
attributes is outside the scope of the charter, at the time this attributes is outside the scope of the charter, at the time this
document was prepared. document was prepared.
o BGPSEC cannot ensure that an AS will withdraw a route when the AS
no longer has a route for a prefix, as noted in Section 4.2.
BGPSEC may incorporate features to limit the lifetime of an
advertisement. Such lifetime limits provide an upper bound on the
time that the failure to withdraw a route will remain effective.
6. Security Considerations 6. Security Considerations
A threat model is, by definition, a security-centric document. A threat model is, by definition, a security-centric document.
Unlike a protocol description, a threat model does not create Unlike a protocol description, a threat model does not create
security problems nor purport to address security problems. This security problems nor purport to address security problems. This
model postulates a set of threats (i.e., motivated, capable model postulates a set of threats (i.e., motivated, capable
adversaries) and examines classes of attacks that these threats are adversaries) and examines classes of attacks that these threats are
capable of effecting, based on the motivations ascribed to the capable of effecting, based on the motivations ascribed to the
threats. It describes the impact of these types of attacks on threats. It describes the impact of these types of attacks on
BGPSEC, including on the RPKI on which BGPSEC relies. It describes BGPSEC, including on the RPKI on which BGPSEC relies. It describes
skipping to change at page 24, line 14 skipping to change at page 24, line 14
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 9.2. Informative References
[I-D.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-13 (work in
progress), May 2011.
[I-D.ietf-sidr-res-certs]
Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates",
draft-ietf-sidr-res-certs-22 (work in progress), May 2011.
[I-D.ietf-sidr-roa-format]
Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)",
draft-ietf-sidr-roa-format-12 (work in progress),
May 2011.
[I-D.ietf-sidr-rpki-manifests]
Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure",
draft-ietf-sidr-rpki-manifests-16 (work in progress),
July 2011.
[I-D.ietf-sidr-signed-object]
Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure",
draft-ietf-sidr-signed-object-04 (work in progress),
May 2011.
[Kent2000] [Kent2000]
Kent, S., Lynn, C., and K. Seo, "Design and Analysis of Kent, S., Lynn, C., and K. Seo, "Design and Analysis of
the Secure Border Gateway Protocol (S-BGP)", IEEE DISCEX the Secure Border Gateway Protocol (S-BGP)", IEEE DISCEX
Conference, June 2000. Conference, June 2000.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004. Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, January 2006. RFC 4272, January 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010. Authentication Option", RFC 5925, June 2010.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure
(RPKI)", RFC 6486, February 2012.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487,
February 2012.
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure
(RPKI)", RFC 6488, February 2012.
[TCPMD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [TCPMD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
Authors' Addresses Authors' Addresses
Stephen Kent Stephen Kent
BBN Technologies BBN Technologies
10 Moulton St. 10 Moulton St.
Cambridge, MA 02138 Cambridge, MA 02138
US US
 End of changes. 15 change blocks. 
68 lines changed or deleted 71 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/