-03 published. sue's octet counts and some reqork of text
This commit is contained in:
parent
a7aacbdd5a
commit
7677a45fe6
1 changed files with 47 additions and 47 deletions
|
|
@ -11,7 +11,7 @@
|
|||
<?rfc tocindent="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>
|
||||
|
||||
|
|
@ -49,10 +49,10 @@
|
|||
|
||||
<abstract>
|
||||
|
||||
<t>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.
|
||||
<t>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.
|
||||
</t>
|
||||
|
||||
</abstract>
|
||||
|
|
@ -120,20 +120,18 @@
|
|||
</artwork>
|
||||
</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>
|
||||
|
||||
<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,
|
||||
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.</t>
|
||||
|
||||
<t>As the ULPC PDU may contain keying material, e.g. <xref
|
||||
target="RFC2385"/>, it SHOULD BE over TLS.</t>
|
||||
|
||||
<?rfc subcompact="yes"?>
|
||||
<t>ULPC Type: A one byte integer denoting the type of the
|
||||
upper-layer protocol
|
||||
|
|
@ -192,10 +190,10 @@
|
|||
family replaces any previous one.</t>
|
||||
|
||||
<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
|
||||
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.</t>
|
||||
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.</t>
|
||||
|
||||
<t>As a link may have multiple encapsulations and multiple
|
||||
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
|
||||
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>
|
||||
|
||||
<t>If a peering address has been announced as a loopback,
|
||||
i.e. MUST BE flagged as such in the L3ND Encapsulation PDU (see
|
||||
<xref target="I-D.ymbk-idr-l3nd"/> 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
|
||||
<t>If a peering address has been announced as a loopback, i.e.
|
||||
MUST BE flagged as such in the L3ND Encapsulation PDU (see <xref
|
||||
target="I-D.ymbk-idr-l3nd"/> 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.</t>
|
||||
|
||||
<t>Attributes MUST be unique in the Attribute List. I.e. a
|
||||
|
|
@ -232,9 +230,9 @@
|
|||
|
||||
<section anchor="asn" title="BGP ASN">
|
||||
|
||||
<t>The Autonomous System number MUST be specified. If the AS
|
||||
Number is less than 32 bits, it is padded with high order
|
||||
zeros.</t>
|
||||
<t>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.</t>
|
||||
|
||||
<figure>
|
||||
<artwork>
|
||||
|
|
@ -256,20 +254,21 @@
|
|||
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
|
||||
peering source address to be used by the receiver. At least one
|
||||
of IPv4 or IPv6 BGP source addresses MUST be announced.</t>
|
||||
<t>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.</t>
|
||||
|
||||
<t>As usual, the BGP OPEN capability negotiation will determine
|
||||
the AFI/SAFIs to be transported over the peering, see <xref
|
||||
target="RFC4760"/> .</t>
|
||||
target="RFC4760"/>.</t>
|
||||
|
||||
<figure>
|
||||
<artwork>
|
||||
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 @@
|
|||
|
||||
<section anchor="bgpv6" title="BGP IPv6 Address">
|
||||
|
||||
<t>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.</t>
|
||||
<t>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.</t>
|
||||
|
||||
<t>As usual, the BGP OPEN capability negotiation will determine
|
||||
the AFI/SAFIs to be transported over the peering, see <xref
|
||||
|
|
@ -321,7 +321,7 @@
|
|||
KARP database (see <xref target="RFC7210"/>), or one of multiple
|
||||
Authentication sub-TLVs to support hop<xref
|
||||
target="RFC4808"/>.</t>
|
||||
|
||||
|
||||
<!--
|
||||
protocol "Attr Type = 4:8,Attr Len:8,BGP Authentication Data ...:48"
|
||||
-->
|
||||
|
|
@ -344,8 +344,8 @@
|
|||
|
||||
<t>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.</t>
|
||||
attributes might be needed, the two octet BGP Miscellaneous
|
||||
Flags sub-TLV may be used.</t>
|
||||
<!--
|
||||
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>
|
||||
<?rfc subcompact="no"?></list></t>
|
||||
|
||||
<t>The GTSM flag indicates that the sender wishes to enable the
|
||||
<xref target="RFC5082"/> Generalized TTL Security Mechanism for
|
||||
the session.</t>
|
||||
<t>The GTSM flag, when 1, indicates that the sender wishes to
|
||||
enable the <xref target="RFC5082"/> Generalized TTL Security
|
||||
Mechanism for the session.</t>
|
||||
|
||||
</section>
|
||||
|
||||
|
|
@ -383,14 +383,14 @@
|
|||
target="I-D.ymbk-idr-l3nd"/> apply to this PDU.</t>
|
||||
|
||||
<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>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.</t>
|
||||
|
||||
</section>
|
||||
|
|
@ -427,7 +427,7 @@
|
|||
|
||||
<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>
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue