diff --git a/draft-ymbk-idr-l3nd-ulpc.xml b/draft-ymbk-idr-l3nd-ulpc.xml index a721544..cb11f25 100644 --- a/draft-ymbk-idr-l3nd-ulpc.xml +++ b/draft-ymbk-idr-l3nd-ulpc.xml @@ -11,7 +11,7 @@ - + @@ -134,6 +134,259 @@ kinds of attacks BGP TCP sessions have endured. So it is what BGP deployments use. + + ULPC Type: An integer denoting the type of the upper-layer + protocol + + Reserved + BGP + Reserved + + + The AttrCount is the number of attribute sub-TLVs in the + Attribute List. + + The Attribute List is a, possibly null, set of sub-TLVs + describing the configuration attributes of the specific upper-layer + protocol. + + An Attribute consists of a one octet Attribute Type, a one octet + Attribute Length of the number of octets in the Attribute, and a + Payload of arbitrary length up to 253 octets. + + + +
+ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attr Type = 1 | Attr Len | Payload | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ + +
+ + The parameters needed for BGP peering on a link are exchanged + in sub-TLVs within an Upper-Layer Protocol PDU. The following + describe the various sub-TLVs for BGP. + + The goal is to provide the minimal set of configuration + parameters needed by BGP OPEN to successfully start a BGP peering. + The goal is specifically not to replace or conflict with data + exchanged during BGP OPEN. Multiple sources of truth are a recipe + for complexity and hence pain. + + If there are multiple BGP sessions on a link, e.g., IPv4 and + IPv6, then multiple sets of BGP sub-TLVs MAY BE exchanged within + the BGP ULPC PDU or multiple BGP ULPC PDUs may be sent, one for + each address family. + + A peer receiving BGP ULPC PDUs has only one active BGP ULPC PDU + for an particular address family on a specific link at any point + in time; receipt of a new BGP ULPC PDU for a particular address + family replaces any previous one. + + If there are one or more open BGP sessions, receipt of a new + BGP ULPC PDU does not affect these sessions and the PDU SHOULD be + discarded. If a peer wishes to replace an open BGP session, they + MUST first close the running BGP session and then send a new BGP + ULPC PDU. + + As a link may have multiple encapsulations and multiple + addresses for an IP encapsulation, which address of which + encapsulation is to be used for the BGP session MUST be + specified. + + For each BGP peering on a link here MUST be one agreed + encapsulation, and the addresses used MUST be in the corresponding + L3DP IPv4/IPv6 Announcement PDUs. If the choice is ambiguous, an + Attribute may be used to signal preferences. + + If a peering address has been announced as a loopback, + i.e. MUST BE flagged as such in the L3DL Encapsulation PDU (see + Sec. 10.3), a two or three + hop BGP session will be established. Otherwise a direct one hop + session is used. The BGP session to a loopback will forward to + the peer's address which was marked as Primary in the L3DL + Encapsulation Flags, iff it is in a subnet which is shared with + both BGP speakers. If the primary is not in a common subnet, then + the BGP speaker MAY pick a forwarding next hop that is in a subnet + they share. If there are multiple choices, the BGP speaker SHOULD + have signaled which subnet to choose in an Upper-Layer Protocol + Configuration PDU Attribute. + + + +
+ + The Autonomous System number MUST be specified. If the AS + Number is less than 32 bits, it is padded with high order + zeros. + +
+ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attr Type = 1 | Attr Len = 6 | My ASN ~ ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +~ | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +
+ +
+ + + + The BGP IPv4 Address sub-TLV announces the sender's IPv4 BGP + peering source address to be used by the receiver. At least one + of IPv4 or IPv6 BGP source addresses MUST be announced. + + As usual, the BGP OPEN capability negotiation will determine + the AFI/SAFIs to be transported over the peering, see . + +
+ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attr Type = 2 | Attr Len = 7 | My IPv4 Peering Address ~ ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +~ | Prefix Len | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +
+ +
+ + The BGP IPv6 Address sub-TLV announces the sender's IPv6 BGP + peering source address to be used by the receiver. At least one + of IPv4 or IPv6 BGP source addresses MUST be announced. + + As usual, the BGP OPEN capability negotiation will determine + the AFI/SAFIs to be transported over the peering, see . + + + +
+ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attr Type = 3 | Attr Len = 19 | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | ++ + +| My IPv6 Peering Address | ++ + +| | ++ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | Prefix Len | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +
+ +
+ + The BGP Authentication sub-TLV provides any authentication + data needed to OPEN the BGP session. Depending on operator + configuration of the environment, it might be a simple MD5 key + (see ), the name of a key chain in a + KARP database (see ), or one of multiple + Authentication sub-TLVs to support hop. + + + +
+ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attr Type = 4 | Attr Len | ~ ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ +~ BGP Authentication Data ... ~ ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +
+ +
+ + The BGP session OPEN has extensive, and a bit complex, + capability negotiation facilities. In case one or more extra + attributes might be needed, the BGP Miscellaneous Flags sub-TLV + may be used. No flags are currently defined. + + +
+ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attr Type = 5 | Attr Len = 4 | Misc Flags | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ + Misc Attrs: + + + GTSM + Must be zero + + + The GTSM flag indicates that the sender wishes to enable the + Generalized TTL Security Mechanism for + the session. + +
+ +
+ + + +
+ + All the Security considerations of apply to this PDU. + + As the ULPC PDU may contain keying material, see , it SHOULD BE signed. + + Any keying material in the PDU SHOULD BE salted and hashed. + + The BGP Authentication sub-TLV provides for provisioning MD5, + which is a quite weak hash, horribly out of fashion, and kills + puppies. But, like it or not, it has been sufficient against the + kinds of attacks BGP TCP sessions have endured. Soit is what BGP + deployments use. +
@@ -179,15 +432,16 @@ - + + - - + +