From 7677a45fe694bca807c5932beddd79e80bae5e91 Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Mon, 7 Mar 2022 13:29:28 -0800 Subject: [PATCH] -03 published. sue's octet counts and some reqork of text --- draft-ymbk-idr-l3nd-ulpc.xml | 94 ++++++++++++++++++------------------ 1 file changed, 47 insertions(+), 47 deletions(-) diff --git a/draft-ymbk-idr-l3nd-ulpc.xml b/draft-ymbk-idr-l3nd-ulpc.xml index 75ecfef..35b1579 100644 --- a/draft-ymbk-idr-l3nd-ulpc.xml +++ b/draft-ymbk-idr-l3nd-ulpc.xml @@ -11,7 +11,7 @@ - + @@ -49,10 +49,10 @@ - This document uses the Layer-3 Neighbor Discovery protocol to - communicate the parameters needed to exchange inter-device Upper - Layer Protocol Configuration for upper-layer protocols such as the - BGP family. + This document adds PDUs to the Layer-3 Neighbor Discovery + protocol to communicate the parameters needed to exchange + inter-device Upper Layer Protocol Configuration for upper-layer + protocols such as the BGP family. @@ -120,20 +120,18 @@ - The Type and Payload Length are defined in The Version, Type, and Payload Length as defined in apply to this PDU. - As the ULPC PDU may contain keying material, e.g. , it SHOULD BE over TLS. - - 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. So it is what BGP deployments use. + As the ULPC PDU may contain keying material, e.g. , it SHOULD BE over TLS. + ULPC Type: A one byte integer denoting the type of the upper-layer protocol @@ -192,10 +190,10 @@ 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. + BGP ULPC PDU SHOULD 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 @@ -204,20 +202,20 @@ 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 + L3ND IPv4/IPv6 Encapsulation 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 L3ND 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 L3ND - 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 + If a peering address has been announced as a loopback, i.e. + MUST BE flagged as such in the L3ND Encapsulation PDU (see Sec. 10.2), a two or three hop BGP + session MUST 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 L3ND 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. Attributes MUST be unique in the Attribute List. I.e. a @@ -232,9 +230,9 @@
- The Autonomous System number MUST be specified. If the AS - Number is less than 32 bits, it is padded with high order - zeros. + The four octet Autonomous System number MUST be specified. + If the AS Number is less than 32 bits, it is padded with high + order zeros.
@@ -256,20 +254,21 @@ protocol "Attr Type = 2:8,Attr Len = 7:8,My IPv4 Peering Address:32,Prefix Len:8" --> - 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. + TheBGP IPv4 Address sub-TLV announces the sender's four octet + IPv4 BGP peering source address and one octet Prefix Lenth 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 . + target="RFC4760"/>.
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 ~ +| Attr Type = 2 | Attr Len = 5 | My IPv4 Peering Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ | Prefix Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -280,9 +279,10 @@
- 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. + The BGP IPv6 Address sub-TLV announces the sender's 16 octet + IPv6 BGP peering source address and one octet Prefix Length 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 ), or one of multiple Authentication sub-TLVs to support hop. - + @@ -344,8 +344,8 @@ 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. + attributes might be needed, the two octet BGP Miscellaneous + Flags sub-TLV may be used. @@ -367,9 +367,9 @@ Must be zero - The GTSM flag indicates that the sender wishes to enable the - Generalized TTL Security Mechanism for - the session. + The GTSM flag, when 1, indicates that the sender wishes to + enable the Generalized TTL Security + Mechanism for the session.
@@ -383,14 +383,14 @@ target="I-D.ymbk-idr-l3nd"/> apply to this PDU. As the ULPC PDU may contain keying material, see , it SHOULD BE signed. + target="bgpmd5"/>, it SHOULD BE over TLS, not clear TCP. 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 + kinds of attacks BGP TCP sessions have endured. So it is what BGP deployments use.
@@ -427,7 +427,7 @@
- The authors thank Rob Austein and Sue Hares. + The authors thank Rob Austein, Sue Hares, and Russ Housley.