[sidr] RFC 8210 on The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1

2017-09-27 Thread rfc-editor 
A new Request for Comments is now available in online RFC libraries.


RFC 8210

Title:  The Resource Public Key Infrastructure 
(RPKI) to Router Protocol, Version 1 
Author: R. Bush, 
R. Austein
Status: Standards Track
Stream: IETF
Date:   September 2017
Mailbox:ra...@psg.com, 
s...@hactrn.net
Pages:  35
Characters: 78467
Updates:RFC 6810

I-D Tag:draft-ietf-sidr-rpki-rtr-rfc6810-bis-09.txt

URL:https://www.rfc-editor.org/info/rfc8210

DOI:10.17487/RFC8210

In order to verifiably validate the origin Autonomous Systems and
Autonomous System Paths of BGP announcements, routers need a simple
but reliable mechanism to receive Resource Public Key Infrastructure
(RFC 6480) prefix origin data and router keys from a trusted cache.
This document describes a protocol to deliver them.

This document describes version 1 of the RPKI-Router protocol.  RFC
6810 describes version 0.  This document updates RFC 6810.

This document is a product of the Secure Inter-Domain Routing Working Group of 
the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] RFC 8209 on A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests

2017-09-27 Thread rfc-editor 
A new Request for Comments is now available in online RFC libraries.


RFC 8209

Title:  A Profile for BGPsec Router 
Certificates, Certificate Revocation Lists, 
and Certification Requests 
Author: M. Reynolds, 
S. Turner,
S. Kent
Status: Standards Track
Stream: IETF
Date:   September 2017
Mailbox:m...@islandpeaksoftware.com, 
s...@sn3rd.com, 
k...@alum.mit.edu
Pages:  15
Characters: 29355
Updates:RFC 6487

I-D Tag:draft-ietf-sidr-bgpsec-pki-profiles-21.txt

URL:https://www.rfc-editor.org/info/rfc8209

DOI:10.17487/RFC8209

This document defines a standard profile for X.509 certificates used
to enable validation of Autonomous System (AS) paths in the Border
Gateway Protocol (BGP), as part of an extension to that protocol
known as BGPsec.  BGP is the standard for inter-domain routing in the
Internet; it is the "glue" that holds the Internet together.  BGPsec
is being developed as one component of a solution that addresses the
requirement to provide security for BGP.  The goal of BGPsec is to
provide full AS path validation based on the use of strong
cryptographic primitives.  The end entity (EE) certificates specified
by this profile are issued to routers within an AS.  Each of these
certificates is issued under a Resource Public Key Infrastructure
(RPKI) Certification Authority (CA) certificate.  These CA
certificates and EE certificates both contain the AS Resource extension.
An EE certificate of this type asserts that
the router or routers holding the corresponding private key are
authorized to emit secure route advertisements on behalf of the
AS(es) specified in the certificate.  This document also profiles the
format of certification requests and specifies Relying Party (RP)
certificate path validation procedures for these EE certificates.
This document extends the RPKI; therefore, this document updates the
RPKI Resource Certificates Profile (RFC 6487).

This document is a product of the Secure Inter-Domain Routing Working Group of 
the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] RFC 8208 on BGPsec Algorithms, Key Formats, and Signature Formats

2017-09-27 Thread rfc-editor 
A new Request for Comments is now available in online RFC libraries.


RFC 8208

Title:  BGPsec Algorithms, Key Formats, and 
Signature Formats 
Author: S. Turner, 
O. Borchert
Status: Standards Track
Stream: IETF
Date:   September 2017
Mailbox:s...@sn3rd.com, 
oliver.borch...@nist.gov
Pages:  19
Characters: 35568
Updates:RFC 7935

I-D Tag:draft-ietf-sidr-bgpsec-algs-18.txt

URL:https://www.rfc-editor.org/info/rfc8208

DOI:10.17487/RFC8208

This document specifies the algorithms, algorithm parameters,
asymmetric key formats, asymmetric key sizes, and signature formats
used in BGPsec (Border Gateway Protocol Security).  This document
updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use 
  
in the Resource Public Key Infrastructure").

This document also includes example BGPsec UPDATE messages as well as
the private keys used to generate the messages and the certificates
necessary to validate those signatures.

This document is a product of the Secure Inter-Domain Routing Working Group of 
the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] BCP 211, RFC 8207 on BGPsec Operational Considerations

2017-09-27 Thread rfc-editor 
A new Request for Comments is now available in online RFC libraries.

BCP 211
RFC 8207

Title:  BGPsec Operational Considerations 
Author: R. Bush
Status: Best Current Practice
Stream: IETF
Date:   September 2017
Mailbox:ra...@psg.com
Pages:  10
Characters: 21086
See Also:   BCP 211

I-D Tag:draft-ietf-sidr-bgpsec-ops-16.txt

URL:https://www.rfc-editor.org/info/rfc8207

DOI:10.17487/RFC8207

Deployment of the BGPsec architecture and protocols has many
operational considerations.  This document attempts to collect and
present the most critical and universal.  Operational practices are
expected to evolve as BGPsec is formalized and initially deployed.

This document is a product of the Secure Inter-Domain Routing Working Group of 
the IETF.


BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] RFC 8206 on BGPsec Considerations for Autonomous System (AS) Migration

2017-09-27 Thread rfc-editor 
A new Request for Comments is now available in online RFC libraries.


RFC 8206

Title:  BGPsec Considerations for 
Autonomous System (AS) Migration 
Author: W. George, 
S. Murphy
Status: Standards Track
Stream: IETF
Date:   September 2017
Mailbox:wesgeo...@puck.nether.net, 
sa...@tislabs.com
Pages:  16
Characters: 36491
Updates:RFC 8205

I-D Tag:draft-ietf-sidr-as-migration-06.txt

URL:https://www.rfc-editor.org/info/rfc8206

DOI:10.17487/RFC8206

This document discusses considerations and methods for supporting and
securing a common method for Autonomous System (AS) migration within
the BGPsec protocol.

This document is a product of the Secure Inter-Domain Routing Working Group of 
the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] RPKI-RTR implementation clues

2017-09-27 Thread Randy Bush 
>> I'm in the process of adding RPKI-RTR (RFC6810) support to OpenBGPd
> This is not directly related to your question, but note that the new
> RFC, standardizing the new version of RTR (version 1, RFC 6810 was
> version 0) is in AUTH48-DONE and can be published any time now
> 

you may also find draft-ymbk-sidrops-ov-clarify-01.txt useful

randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] RPKI-RTR implementation clues

2017-09-27 Thread Borchert, Oliver (Fed) 
Hi Dennis,

The issue is not only with new BGP updates you receive during the cache update, 
the issue is also how to treat already received updates.
The safest is to operate with the RPKI state known prior the start of a cache 
update. Once the cache is updated, re-evaluate all 
BGP updates you know already using the new RPKI information.

Oliver

-Original Message-
From: sidr [mailto:sidr-boun...@ietf.org] On Behalf Of Ruediger Volk
Sent: Wednesday, September 27, 2017 5:54 AM
To: Denis Fondras 
Cc: r...@limes.nic.dtag.de; sidr@ietf.org
Subject: Re: [sidr] RPKI-RTR implementation clues

Hi Denis,
  > Hi,
  >
  > I'm in the process of adding RPKI-RTR (RFC6810) support to OpenBGPd and I am
  > wondering about how others have implemented it.
great to hear about implementation efforts for another (nice) BGP 
implementation.

  > - How is the process started ?
  > Currently, when I start bgpd, it will fetch a list of VRP from the cache
  > and at the same time get prefixes from its peers.  As soon as it gets
  > a VRP, it will
  > try to validate prefixes in the RIB. The goal is to get a state as sooner as
  > possible to apply filters if needed.
  > The problem is I can have an unknown state in the case a prefix tries to get
  > validated while the VRP list is not complete. The solution is to make anoth 
er
  > round of validation when I get a complete VRP list.
  > Do you wait until you get a complete VRP list (ENDOFDATA message) before
  > starting the validation process ?
it is a bad idea to do origin validation based on incomplete cache state.
For example consider that a more specific (e.g. beef:dead::/32) will be 
classified INVALID if there is a matching ROA but only a covering but NOT 
matching aggregate ROA (e.g. beef::/16-16) is available before the more 
specific VRP.

  > - How are subsequent validation handled ?
  > Do you start the validation process as soon as you get a new VRP or do you 
wait
  > for a refresh timer ? In the former, a prefix could stay in the wrong state 
 for
  > some time. I am assuming that every new prefix is validated as it arrives.
Lazy origin validation classification is allowed (but it implies that besides 
unknown/valid/invalid you should support a 4th class of "unclassified"
is needed). It's great if recceived announcements are immediately classified
- but that can only be done correctly against a complete cache state.

  > Thank you in advance,
  > Denis
  >
  > ___
  > sidr mailing list
  > sidr@ietf.org
  > https://www.ietf.org/mailman/listinfo/sidr

Ruediger Volk

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] RPKI-RTR implementation clues

2017-09-27 Thread Denis Fondras 
> - How are subsequent validation handled ?
> Do you start the validation process as soon as you get a new VRP or do you 
> wait
> for a refresh timer ? In the former, a prefix could stay in the wrong state 
> for
   ^^^ latter

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] RPKI-RTR implementation clues

2017-09-27 Thread Denis Fondras 
Hi,

I'm in the process of adding RPKI-RTR (RFC6810) support to OpenBGPd and I am
wondering about how others have implemented it.

- How is the process started ?
Currently, when I start bgpd, it will fetch a list of VRP from the cache and at
the same time get prefixes from its peers.  As soon as it gets a VRP, it will
try to validate prefixes in the RIB. The goal is to get a state as sooner as
possible to apply filters if needed.
The problem is I can have an unknown state in the case a prefix tries to get
validated while the VRP list is not complete. The solution is to make another
round of validation when I get a complete VRP list.
Do you wait until you get a complete VRP list (ENDOFDATA message) before
starting the validation process ?

- How are subsequent validation handled ?
Do you start the validation process as soon as you get a new VRP or do you wait
for a refresh timer ? In the former, a prefix could stay in the wrong state for
some time. I am assuming that every new prefix is validated as it arrives.

Thank you in advance,
Denis

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr