draft-ietf-sidr-bogons-01.txt   draft-ietf-sidr-bogons-02.txt 
Individual Submission G. Huston Secure Inter-Domain Routing (SIDR) G. Huston
Internet-Draft G. Michaelson Internet-Draft G. Michaelson
Intended status: Standards Track APNIC Intended status: Standards Track APNIC
Expires: April 8, 2009 T. Manderson Expires: May 2, 2009 T. Manderson
October 5, 2008 October 29, 2008
A Profile for Bogon Origin Attestations (BOAs) A Profile for Bogon Origin Attestations (BOAs)
draft-ietf-sidr-bogons-01.txt draft-ietf-sidr-bogons-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 8, 2009. This Internet-Draft will expire on May 2, 2009.
Abstract Abstract
This document defines a standard profile for Bogon Origin This document defines a standard profile for Bogon Origin
Attestations (BOAs). A BOA is a digitally signed object that Attestations (BOAs). A BOA is a digitally signed object that
provides a means of verifying that an IP address block holder has not provides a means of verifying that an IP address block holder has not
authorized any Autonomous System (AS) to originate routes that are authorized any Autonomous System (AS) to originate routes that are
equivalent to any of the addresses listed in the BOA. A BOA also equivalent to any of the addresses listed in the BOA. A BOA also
provides a means of verifying that BGP speaker is not using an AS provides a means of verifying that BGP speaker is not using an AS
without appropriate authority to use that AS. The proposed without appropriate authority to use that AS. The proposed
skipping to change at page 3, line 24 skipping to change at page 3, line 24
The RPKI is based on Resource Certificates. Resource Certificates The RPKI is based on Resource Certificates. Resource Certificates
are X.509 certificates that conform to the PKIX profile [RFC5280], are X.509 certificates that conform to the PKIX profile [RFC5280],
and to the extensions for IP addresses and AS identifiers [RFC3779]. and to the extensions for IP addresses and AS identifiers [RFC3779].
A Resource Certificate describes an action by an Issuer that binds a A Resource Certificate describes an action by an Issuer that binds a
list of IP address blocks and Autonomous System (AS) numbers to the list of IP address blocks and Autonomous System (AS) numbers to the
Subject of a certificate, identified by the unique association of the Subject of a certificate, identified by the unique association of the
Subject's private key with the public key contained in the Resource Subject's private key with the public key contained in the Resource
Certificate. The RPKI is structured such that each current Resource Certificate. The RPKI is structured such that each current Resource
Certificate matches a current resource allocation or assignment. Certificate matches a current resource allocation or assignment.
This is described in [ID.ietf-sidr-arch]. This is described in [ID.sidr-arch].
BOAs can be regarded as a logical opposite of a Route Origin BOAs can be regarded as a logical opposite of a Route Origin
Authorization (ROA) [ID.ietf-sidr-roa-format], and allows a resource Authorization (ROA) [ID.sidr-roa-format], and allows a resource
holder to explicitly list those IP addresses and AS's that are holder to explicitly list those IP addresses and AS's that are
denoted by the holder as not validly appearing in any routing denoted by the holder as not validly appearing in any routing
advertisement, and to make this attestation in a manner that a advertisement, and to make this attestation in a manner that a
relying party can validate under the framework of the RPKI. relying party can validate under the framework of the RPKI.
A BOA is a digitally signed object that makes use of Cryptographic A BOA is a digitally signed object that makes use of Cryptographic
Message Syntax (CMS) [RFC3852] as a standard encapsulation format. Message Syntax (CMS) [RFC3852] as a standard encapsulation format.
CMS was chosen to take advantage of existing open source software CMS was chosen to take advantage of existing open source software
available for processing messages in this format. available for processing messages in this format.
skipping to change at page 6, line 15 skipping to change at page 6, line 15
2.1.3.2.3. BOAIPAddressFamily 2.1.3.2.3. BOAIPAddressFamily
The BOAIPAddressFamily field encodes the set of IP address prefixes The BOAIPAddressFamily field encodes the set of IP address prefixes
that are to be regarded as Bogon IP addresses that are to be that are to be regarded as Bogon IP addresses that are to be
constrained from appearing in any routing advertisement. The constrained from appearing in any routing advertisement. The
intended semantics of an address prefix in a BOA is that any route intended semantics of an address prefix in a BOA is that any route
object that has the same address prefix as that listed as a Bogon IP object that has the same address prefix as that listed as a Bogon IP
address, or is a more specific prefix of a Bogon IP address can be address, or is a more specific prefix of a Bogon IP address can be
regarded as a Bogon route object. regarded as a Bogon route object.
The syntax of the addres prefixes listed in a BOA uses a subset of The syntax of the address prefixes listed in a BOA uses a subset of
the IP Address Delegation extension defined in [RFC3779]. The the IP Address Delegation extension defined in [RFC3779]. The
BOAIPAddressFamily cannot contain arbitrary address ranges, but in BOAIPAddressFamily cannot contain arbitrary address ranges, but in
all other respects uses the same canonical format as the IP Address all other respects uses the same canonical format as the IP Address
Delegation Extension. Delegation Extension.
Within the BOAIPAddressFamily structure, addressFamily contains the Within the BOAIPAddressFamily structure, addressFamily contains the
Address Family Identifier (AFI) of an IP address family. This Address Family Identifier (AFI) of an IP address family. This
specification only supports IPv4 and IPv6. Therefore, addressFamily specification only supports IPv4 and IPv6. Therefore, addressFamily
MUST be either 0001 or 0002. The addresses field represents prefixes MUST be either 0001 or 0002. The addresses field represents prefixes
as a sequence of type IPAddress, as defined in[RFC3779]. as a sequence of type IPAddress, as defined in[RFC3779].
skipping to change at page 11, line 7 skipping to change at page 11, line 7
on the BOA. on the BOA.
3. Verify that the EE certificate has an IP Address Delegation 3. Verify that the EE certificate has an IP Address Delegation
extension [RFC3779] and that the IP address prefixes in that extension [RFC3779] and that the IP address prefixes in that
extension exactly match the IP address prefixes in the BOA, and extension exactly match the IP address prefixes in the BOA, and
the AS numbers in that extension exactly match the AS numbers in the AS numbers in that extension exactly match the AS numbers in
the BOA. the BOA.
4. Verify that the EE certificate is a valid end-entity certificate 4. Verify that the EE certificate is a valid end-entity certificate
in the resource PKI by constructing a valid certificate path to a in the resource PKI by constructing a valid certificate path to a
trust anchor. (See [ID.ietf-sidr-res-certs] for more details.) trust anchor. (See [ID.sidr-res-certs] for more details.)
Note that requiring an exact match between the IP address prefixes Note that requiring an exact match between the IP address prefixes
and AS's in a BOA and the IP address prefixes and AS's in the and AS's in a BOA and the IP address prefixes and AS's in the
corresponding EE certificate does not place any limitations on BOA corresponding EE certificate does not place any limitations on BOA
use. Since each EE certificate in the RPKI architecture is used to use. Since each EE certificate in the RPKI architecture is used to
verify only a single BOA, it is natural to have the IP address verify only a single BOA, it is natural to have the IP address
prefixes in the certificate match those in the corresponding BOA. prefixes in the certificate match those in the corresponding BOA.
4. BOA Use Practices 4. BOA Use Practices
skipping to change at page 12, line 7 skipping to change at page 12, line 7
a new EE certificate for a BOA is issued the previous BOA's EE a new EE certificate for a BOA is issued the previous BOA's EE
certificate should be revoked and the previous BOA removed from the certificate should be revoked and the previous BOA removed from the
publication repository. publication repository.
Parties that operate a local cache of RPKI objects should ensure that Parties that operate a local cache of RPKI objects should ensure that
they refresh BOA objects at intervals 24 hours to ensure that they they refresh BOA objects at intervals 24 hours to ensure that they
have the current BOA in the local cache. have the current BOA in the local cache.
5. BOA Interpretation 5. BOA Interpretation
A BOA can be used to check a route object to determine if the A BOA can be used to check an inter-domain routing advertisement
origination information in the route object refers to invalid IP ("route object") to determine if the origination information in the
addresses or an invalid AS number. route object refers to invalid IP addresses or an invalid AS number.
If a route object has an AS origination that refers to an AS number If a route object has an AS origination that refers to an AS number
that is included in a valid BOA then the route object can be regarded that is listed in a valid BOA, then the route object can be regarded
as a Bogon object, and local policies that apply to Bogon AS's can be as a Bogon object, and local policies that apply to Bogon AS's can be
applied to the object. This holds whether or not the address prefix applied to the object. This holds whether or not the address prefix
of the route object is described by a valid ROA or not. of the route object is described by a valid ROA or not.
If a route object has an address prefix that is equal to, or is a If a route object has an address prefix that is equal to, or is a
more specific prefix of an IP address that is included in a valid BOA more specific prefix of an IP address that is included in a valid BOA
then the route object can be regarded as a Bogon object, and local then the route object can be regarded as a Bogon object, and local
policies that apply to Bogon AS's can be applied to the object, policies that apply to Bogon AS's can be applied to the object,
unless the address prefix and AS origination of the route object is unless the address prefix and AS origination of the route object is
also described by a valid ROA, in which case the BOA is to be also described by a valid ROA, in which case the BOA is to be
disregarded. In other words a valid ROA SHOULD infer a higher trust disregarded. In other words, a valid ROA SHOULD infer a higher local
preference than a ROA if a valid ROA and BOA exist for the same trust preference than a BOA if a valid ROA and a valid BOA both exist
address prefix and AS number. that refer to the same address prefix.
BOA interpretation in the context of validation of origination of
route objects is described in [ID.sidr-roa-validation].
6. Security Considerations 6. Security Considerations
There is no assumption of confidentiality for the data in a BOA; it There is no assumption of confidentiality for the data in a BOA; it
is anticipated that BOAs will be stored in repositories that are is anticipated that BOAs will be stored in repositories that are
accessible to all ISPs, and perhaps to all Internet users. There is accessible to all ISPs, and perhaps to all Internet users. There is
no explicit authentication associated with a BOA, since the RPKI used no explicit authentication associated with a BOA, since the RPKI used
for BOA validation provides authorization but not authentication. for BOA validation provides authorization but not authentication.
Although the BOA is a signed, application layer object, there is no Although the BOA is a signed, application layer object, there is no
intent to convey non-repudiation via a BOA. intent to convey non-repudiation via a BOA.
The purpose of a BOA is to convey an attestation by an address holder The purpose of a BOA is to convey an attestation by an address holder
that there is no authority for the generation of a route object that that there is no authority for the generation of a route object that
refers to specified addresses or origination from specified AS's. refers to specified addresses or origination from specified AS's.
The integrity of a BOA must be established in order to validate the The integrity of a BOA must be established in order to validate the
authority of the Bogon Attestation. The BOA makes use of the CMS authority of the Bogon Attestation. The BOA makes use of the CMS
signed message format for integrity, and thus inherits the security signed message format for integrity, and thus inherits the security
considerations associated with that data structure. The right of the considerations associated with that data structure. The right of the
BOA signer to authorize the attestation of specified IP addresses and BOA signer to authorize the attestation of specified IP addresses and
AS's as Bogons is established through use of the address space and AS AS's as Bogons is established through use of the address space and AS
number PKI described in [ID.ietf-sidr-arch]. Specifically, a relying number PKI described in [ID.sidr-arch]. Specifically, a relying
party must verify the signature on the BOA using an X.509 certificate party must verify the signature on the BOA using an X.509 certificate
issued under this PKI, and check that the prefix(es) in the BOA match issued under this PKI, and check that the prefix(es) in the BOA match
those in the address space extension in the certificate. those in the address space extension in the certificate.
7. IANA Considerations 7. IANA Considerations
[None] [None]
8. Acknowledgments 8. Acknowledgments
The authors are indebted to the authors of Route Origin Authorization The authors are indebted to the authors of Route Origin Authorization
(ROA) [ID.ietf-sidr-roa-format], M. Lepinski, S. Kent and D. Kong, as (ROA) [ID.sidr-roa-format], M. Lepinski, S. Kent and D. Kong, as much
much of the text used to define a BOA has been borrowed from the ROA of the text used to define a BOA has been borrowed from the ROA
format specification, and Russ Housley for clarification on the CMS format specification, and Russ Housley for clarification on the CMS
profile. profile.
9. Normative References 9. Normative References
[ID.ietf-sidr-arch] [ID.sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch (work in Secure Internet Routing", draft-ietf-sidr-arch (work in
progress), February 2008. progress), February 2008.
[ID.ietf-sidr-res-certs] [ID.sidr-res-certs]
Huston, G., Michaleson, G., and R. Loomans, "A Profile for Huston, G., Michaleson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", Internet X.509 PKIX Resource Certificates", Internet
Draft draft-ietf-sidr-res-certs, August 2008. Draft draft-ietf-sidr-res-certs, August 2008.
[ID.ietf-sidr-roa-format] [ID.sidr-roa-format]
Lepinski, M., Kent, S., and D. Kong, "An Infrastructure to Lepinski, M., Kent, S., and D. Kong, "An Infrastructure to
Support Secure Internet Routing", Support Secure Internet Routing",
draft-ietf-sidr-roa-format (work in progress), July 2008. draft-ietf-sidr-roa-format (work in progress), July 2008.
[ID.sidr-roa-validation]
Huston, G. and G. Michaelson, "Validation of Route
Origination in BGP using the Resource Certificate PKI",
draft-ietf-sidr-roa-validation (work in progress),
October 2008.
[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.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004. RFC 3852, July 2004.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055, and Certificate Revocation List (CRL) Profile", RFC 4055,
 End of changes. 17 change blocks. 
22 lines changed or deleted 31 lines changed or added

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