randy/draft-l3nd-ulpc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

-03 published. sue's octet counts and some reqork of text

Browse source
This commit is contained in:
Randy Bush 2022-03-07 13:29:28 -08:00
parent a7aacbdd5a
commit 7677a45fe6
1 changed files with 47 additions and 47 deletions
Download patch file Download diff file Expand all files Collapse all files

92
draft-ymbk-idr-l3nd-ulpc.xml
View file

@ -11,7 +11,7 @@
<?rfc tocindent="yes"?> <?rfc tocindent="yes"?>
<?rfc tocompact="yes"?> <?rfc tocompact="yes"?>
<rfc consensus="yes" category="std" submissionType="IETF" docName="draft-ymbk-idr-l3nd-ulpc-02" ipr="trust200902"> <rfc consensus="yes" category="std" submissionType="IETF" docName="draft-ymbk-idr-l3nd-ulpc-03" ipr="trust200902">
<front> <front>
@ -49,10 +49,10 @@
<abstract> <abstract>
<t>This document uses the Layer-3 Neighbor Discovery protocol to <t>This document adds PDUs to the Layer-3 Neighbor Discovery
communicate the parameters needed to exchange inter-device Upper protocol to communicate the parameters needed to exchange
Layer Protocol Configuration for upper-layer protocols such as the inter-device Upper Layer Protocol Configuration for upper-layer
BGP family. protocols such as the BGP family.
</t> </t>
</abstract> </abstract>
@ -120,20 +120,18 @@
</artwork> </artwork>
</figure> </figure>
<t>The Type and Payload Length are defined in <xref <t>The Version, Type, and Payload Length as defined in <xref
target="I-D.ymbk-idr-l3nd"/> apply to this PDU.</t> target="I-D.ymbk-idr-l3nd"/> apply to this PDU.</t>
<t>As the ULPC PDU may contain keying material, e.g. <xref
target="RFC2385"/>, it SHOULD BE over TLS.</t>
<t>Any keying material in the PDU SHOULD BE salted and hashed.</t>
<t>The BGP Authentication sub-TLV provides for provisioning MD5, <t>The BGP Authentication sub-TLV provides for provisioning MD5,
which is a quite weak hash, horribly out of fashion, and kills which is a quite weak hash, horribly out of fashion, and kills
puppies. But, like it or not, it has been sufficient against the 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 kinds of attacks BGP TCP sessions have endured. So it is what BGP
deployments use.</t> deployments use.</t>
<t>As the ULPC PDU may contain keying material, e.g. <xref
target="RFC2385"/>, it SHOULD BE over TLS.</t>
<?rfc subcompact="yes"?> <?rfc subcompact="yes"?>
<t>ULPC Type: A one byte integer denoting the type of the <t>ULPC Type: A one byte integer denoting the type of the
upper-layer protocol upper-layer protocol
@ -192,10 +190,10 @@
family replaces any previous one.</t> family replaces any previous one.</t>
<t>If there are one or more open BGP sessions, receipt of a new <t>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 BGP ULPC PDU SHOULD not affect these sessions and the PDU SHOULD
discarded. If a peer wishes to replace an open BGP session, they be discarded. If a peer wishes to replace an open BGP session,
MUST first close the running BGP session and then send a new BGP they MUST first close the running BGP session and then send a new
ULPC PDU.</t> BGP ULPC PDU.</t>
<t>As a link may have multiple encapsulations and multiple <t>As a link may have multiple encapsulations and multiple
addresses for an IP encapsulation, which address of which addresses for an IP encapsulation, which address of which
@ -204,20 +202,20 @@
<t>For each BGP peering on a link here MUST be one agreed <t>For each BGP peering on a link here MUST be one agreed
encapsulation, and the addresses used MUST be in the corresponding 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.</t> Attribute may be used to signal preferences.</t>
<t>If a peering address has been announced as a loopback, <t>If a peering address has been announced as a loopback, i.e.
i.e. MUST BE flagged as such in the L3ND Encapsulation PDU (see MUST BE flagged as such in the L3ND Encapsulation PDU (see <xref
<xref target="I-D.ymbk-idr-l3nd"/> Sec. 10.3), a two or three target="I-D.ymbk-idr-l3nd"/> Sec. 10.2), a two or three hop BGP
hop BGP session will be established. Otherwise a direct one hop session MUST be established. Otherwise a direct one hop session
session is used. The BGP session to a loopback will forward to is used. The BGP session to a loopback will forward to the peer's
the peer's address which was marked as Primary in the L3ND address which was marked as Primary in the L3ND Encapsulation
Encapsulation Flags, iff it is in a subnet which is shared with Flags, iff it is in a subnet which is shared with both BGP
both BGP speakers. If the primary is not in a common subnet, then speakers. If the primary is not in a common subnet, then the BGP
the BGP speaker MAY pick a forwarding next hop that is in a subnet speaker MAY pick a forwarding next hop that is in a subnet they
they share. If there are multiple choices, the BGP speaker SHOULD share. If there are multiple choices, the BGP speaker SHOULD have
have signaled which subnet to choose in an Upper-Layer Protocol signaled which subnet to choose in an Upper-Layer Protocol
Configuration PDU Attribute.</t> Configuration PDU Attribute.</t>
<t>Attributes MUST be unique in the Attribute List. I.e. a <t>Attributes MUST be unique in the Attribute List. I.e. a
@ -232,9 +230,9 @@
<section anchor="asn" title="BGP ASN"> <section anchor="asn" title="BGP ASN">
<t>The Autonomous System number MUST be specified. If the AS <t>The four octet Autonomous System number MUST be specified.
Number is less than 32 bits, it is padded with high order If the AS Number is less than 32 bits, it is padded with high
zeros.</t> order zeros.</t>
<figure> <figure>
<artwork> <artwork>
@ -256,20 +254,21 @@
protocol "Attr Type = 2:8,Attr Len = 7:8,My IPv4 Peering Address:32,Prefix Len:8" protocol "Attr Type = 2:8,Attr Len = 7:8,My IPv4 Peering Address:32,Prefix Len:8"
--> -->
<t>The BGP IPv4 Address sub-TLV announces the sender's IPv4 BGP <t>TheBGP IPv4 Address sub-TLV announces the sender's four octet
peering source address to be used by the receiver. At least one IPv4 BGP peering source address and one octet Prefix Lenth to be
of IPv4 or IPv6 BGP source addresses MUST be announced.</t> used by the receiver. At least one of IPv4 or IPv6 BGP source
addresses MUST be announced.</t>
<t>As usual, the BGP OPEN capability negotiation will determine <t>As usual, the BGP OPEN capability negotiation will determine
the AFI/SAFIs to be transported over the peering, see <xref the AFI/SAFIs to be transported over the peering, see <xref
target="RFC4760"/> .</t> target="RFC4760"/>.</t>
<figure> <figure>
<artwork> <artwork>
0 1 2 3 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 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 | ~ | Prefix Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@ -280,9 +279,10 @@
<section anchor="bgpv6" title="BGP IPv6 Address"> <section anchor="bgpv6" title="BGP IPv6 Address">
<t>The BGP IPv6 Address sub-TLV announces the sender's IPv6 BGP <t>The BGP IPv6 Address sub-TLV announces the sender's 16 octet
peering source address to be used by the receiver. At least one IPv6 BGP peering source address and one octet Prefix Length to
of IPv4 or IPv6 BGP source addresses MUST be announced.</t> be used by the receiver. At least one of IPv4 or IPv6 BGP
source addresses MUST be announced.</t>
<t>As usual, the BGP OPEN capability negotiation will determine <t>As usual, the BGP OPEN capability negotiation will determine
the AFI/SAFIs to be transported over the peering, see <xref the AFI/SAFIs to be transported over the peering, see <xref
@ -344,8 +344,8 @@
<t>The BGP session OPEN has extensive, and a bit complex, <t>The BGP session OPEN has extensive, and a bit complex,
capability negotiation facilities. In case one or more extra capability negotiation facilities. In case one or more extra
attributes might be needed, the BGP Miscellaneous Flags sub-TLV attributes might be needed, the two octet BGP Miscellaneous
may be used.</t> Flags sub-TLV may be used.</t>
<!-- <!--
protocol "Attr Type = 5:8,Attr Len = 4:8,Misc Flags:16" protocol "Attr Type = 5:8,Attr Len = 4:8,Misc Flags:16"
--> -->
@ -367,9 +367,9 @@
<t hangText="Bit 1-15:">Must be zero</t> <t hangText="Bit 1-15:">Must be zero</t>
<?rfc subcompact="no"?></list></t> <?rfc subcompact="no"?></list></t>
<t>The GTSM flag indicates that the sender wishes to enable the <t>The GTSM flag, when 1, indicates that the sender wishes to
<xref target="RFC5082"/> Generalized TTL Security Mechanism for enable the <xref target="RFC5082"/> Generalized TTL Security
the session.</t> Mechanism for the session.</t>
</section> </section>
@ -383,14 +383,14 @@
target="I-D.ymbk-idr-l3nd"/> apply to this PDU.</t> target="I-D.ymbk-idr-l3nd"/> apply to this PDU.</t>
<t>As the ULPC PDU may contain keying material, see <xref <t>As the ULPC PDU may contain keying material, see <xref
target="bgpmd5"/>, it SHOULD BE signed.</t> target="bgpmd5"/>, it SHOULD BE over TLS, not clear TCP.</t>
<t>Any keying material in the PDU SHOULD BE salted and hashed.</t> <t>Any keying material in the PDU SHOULD BE salted and hashed.</t>
<t>The BGP Authentication sub-TLV provides for provisioning MD5, <t>The BGP Authentication sub-TLV provides for provisioning MD5,
which is a quite weak hash, horribly out of fashion, and kills which is a quite weak hash, horribly out of fashion, and kills
puppies. But, like it or not, it has been sufficient against the 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.</t> deployments use.</t>
</section> </section>
@ -427,7 +427,7 @@
<section anchor="acks" title="Acknowledgments"> <section anchor="acks" title="Acknowledgments">
<t>The authors thank Rob Austein and Sue Hares.</t> <t>The authors thank Rob Austein, Sue Hares, and Russ Housley.</t>
</section> </section>