Archive for IETF

RFC 9632: Finding and Using Geofeed Data

RFC 9632
Title: Finding and Using Geofeed Data
Author: R. Bush,
        M. Candela,
        W. Kumari,
        R. Housley
Status: Standards Track
Obsoletes: 9092
Stream: IETF
Date: August 2024
URL: https://www.rfc-editor.org/info/rfc9632
DOI: 10.17487/RFC9632

This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to geofeed comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure (RPKI) to authenticate the geofeed data files. This document obsoletes RFC 9092.

Comments off

RFC 9455: Avoiding Route Origin Authorizations (ROAs) Containing Multiple IP Prefixes

RFC 9455
Title: Avoiding Route Origin Authorizations (ROAs) Containing Multiple IP Prefixes
Author: Z. Yan,
        R. Bush,
        G. Geng,
        T. de Kock,
        J. Yao
Status: Standards Track
Stream: IETF
Date: August 2023
URL: https://www.rfc-editor.org/info/rfc9455
DOI: 10.17487/RFC9455

When using the Resource Public Key Infrastructure (RPKI), address space holders need to issue Route Origin Authorization (ROA) object(s) to authorize one or more Autonomous Systems (ASes) to originate BGP routes to IP address prefix(es). This memo discusses operational problems that may arise from ROAs containing multiple IP prefixes and recommends that each ROA contain a single IP prefix.

Comments off

RFC 9324: Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh

RFC 9324
Title: Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh
Author: R. Bush,
        K. Patel,
        P. Smith,
        M. Tinka
Status: Standards Track
Stream: IETF
Date: December 2022
URL: https://www.rfc-editor.org/info/rfc9324
DOI: 10.17487/RFC9324

A BGP speaker performing policy based on the Resource Public Key Infrastructure (RPKI) should not issue route refresh to its neighbors because it has received new RPKI data. This document updates RFC 8481 by describing how to avoid doing so by either keeping a full Adj-RIB-In or saving paths dropped due to ROV (Route Origin Validation) so they may be reevaluated with respect to new RPKI data.

Comments off

RFC 9255: The ‘I’ in RPKI Does Not Stand for Identity

RFC 9255
Title: The 'I' in RPKI Does Not Stand for Identity
Authors: R. Bush,
         R. Housley
Status: Standards Track
Stream: IETF
Date: June 2022
URL: https://www.rfc-editor.org/info/rfc9255
DOI: DOI: 10.17487/RFC9255

There is a false notion that Internet Number Resources (INRs) in the RPKI can be associated with the real-world identity of the ‘holder’ of an INR. This document specifies that RPKI does not associate to the INR holder.

Comments off

RFC 9234: Route Leak Prevention and Detection Using Roles in UPDATE and OPEN

RFC 9234
Title: Route Leak Prevention and Detection Using Roles in UPDATE and OPEN
Author: A. Azimov,
        E. Bogomazov,
        R. Bush,
        K. Patel,
        K. Sriram
Status: Standards Track
Stream: IETF
Date: May 2022
URL: https://www.rfc-editor.org/info/rfc9234
DOI: DOI: 10.17487/RFC9234

Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transit provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a transit provider. These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between autonomous systems (ASes). Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the External BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the peering relationship. This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in order to enforce appropriate configuration on both sides. Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks.

Comments off

RFC 9092: Finding and Using Geofeed Data

RFC 9092
Title: Finding and Using Geofeed Data
Author: R. Bush,
        M. Candela,
        W. Kumari,
        R. Housley
Status: Standards Track
Stream: IETF
Date: July 2021
URL: https://www.rfc-editor.org/info/rfc9020
DOI: 10.17487/RFC9089

This document specifies how to augment the Routing Policy Specification Language inetnum: class to refer specifically to geofeed data comma-separated values (CSV) files and describes an optional scheme that uses the Routing Public Key Infrastructure to authenticate the geofeed data CSV files.

Comments off

RFC 8893: Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export

RFC 8893 
Title: Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export 
Author: R. Bush, 
        R. Volk,
        J. Heitz
Status: Standards Track 
Stream: IETF 
Date: September 2020 
Updates: RFC 6811 
URL: https://www.rfc-editor.org/info/rfc8893 
DOI: 10.17487/RFC8893

A BGP speaker may perform Resource Public Key Infrastructure (RPKI) origin validation not only on routes received from BGP neighbors and routes that are redistributed from other routing protocols, but also on routes it sends to BGP neighbors. For egress policy, it is important that the classification use the ‘effective origin AS’ of the processed route, which may specifically be altered by the commonly available knobs, such as removing private ASes, confederation handling, and other modifications of the origin AS.

Comments off

RFC 8654: Extended Message Support for BGP

    RFC 8654
    Title:      Extended Message Support for BGP
    Author:     R. Bush,
                K. Patel,
                D. Ward
    Status:     Standards Track
    Stream:     IETF
    Date:       October 2019
    Mailbox:    randy@psg.com,
                keyur@arrcus.com,
                dward@cisco.com
    Pages:      7
    Updates:    RFC 4271
    I-D Tag:    draft-ietf-idr-bgp-extended-messages-36.txt
    URL:        https://www.rfc-editor.org/info/rfc8654
    DOI:        10.17487/RFC8654

The BGP specification (RFC 4271) mandates a maximum BGP message size of 4,096 octets. As BGP is extended to support new Address Family Identifiers (AFIs), Subsequent AFIs (SAFIs), and other features, there is a need to extend the maximum message size beyond 4,096 octets. This document updates the BGP specification by extending the maximum message size from 4,096 octets to 65,535 octets for all messages except for OPEN and KEEPALIVE messages.

Comments off

RFC 8642: Policy Behavior for Well-Known BGP Communities

 RFC 8642
 Title:      Policy Behavior for Well-Known BGP  Communities 
 Author:     J. Borkenhagen, 
             R. Bush,
             R. Bonica, 
             S. Bayraktar
 Status:     Standards Track
 Stream:     IETF
 Date:       August 2019
 Pages:      7
 Characters: 13429
 Updates:    RFC 1997
 I-D Tag:    draft-ietf-grow-wkc-behavior-08.txt
 URL:        https://www.rfc-editor.org/info/rfc8642
 DOI:        10.17487/RFC8642

Well-known BGP communities are manipulated differently across various current implementations, resulting in difficulties for operators. Network operators should deploy consistent community handling across their networks while taking the inconsistent behaviors from the various BGP implementations into consideration. This document recommends specific actions to limit future inconsistency: namely, BGP implementors must not create further inconsistencies from this point forward. These behavioral changes, though subtle, actually update RFC 1997.

Comments off

RFC 8635 Router Keying for BGPsec

 RFC 8635
 Title:      Router Keying for BGPsec 
 Author:     R. Bush,
             S. Turner,
             K. Patel
 Status:     Standards Track
 Stream:     IETF
 Date:       August 2019
 I-D Tag:    draft-ietf-sidrops-rtr-keying-06.txt
 URL:        https://www.rfc-editor.org/info/rfc8635
 DOI:        10.17487/RFC8635

BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the Global Resource Public Key Infrastructure (RPKI), enabling verification of BGPsec messages. This document describes two methods of generating the public-private key pairs: router-driven and operator-driven.

Comments off

« Previous entries Next Page » Next Page »