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

cut of revised serial wrap

Browse source
This commit is contained in:
Randy Bush 2021-10-13 16:53:00 -07:00
parent d4d80cf4a9
commit a29cbb21ee
1 changed files with 65 additions and 40 deletions
Download patch file Download diff file Expand all files Collapse all files

105
draft-ietf-lsvr-l3dl.xml
View file

@ -11,7 +11,7 @@
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<rfc category="std" docName="draft-ietf-lsvr-l3dl-07" ipr="trust200902">
<rfc consensus="yes" category="std" docName="draft-ietf-lsvr-l3dl-08" ipr="trust200902">
<front>
@ -413,7 +413,7 @@
fragments are not ACK paced (as PDUs are), to avoid overwhelming
bursts, the sender should pace fragments of a large PDU.</t>
<t>L3DL is carrying relatively small amounts of data on relatively
<t>L3DL is carrying a relatively small amount of data on relatively
high bandwidth links, and at a time when the link is not active with
other data as it does not yet have layer-3 connectivity. So
congestion is not considered a sufficiently significant risk to
@ -786,24 +786,24 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<!--
protocol "PDU Type = 1:8,Payload Length:32,Nonce:32,LLEI Length:8,My LLEI:32,AttrCount:8,Attribute List ...:24,Auth Type:8,Key Length:16,Key ...:24,Serial Number:32,Sig Type:8,Signature Length:16,Signature ...:8"
q-->
-->
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Type = 1 | Payload Length ~
| PDU Type = 1 | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Nonce ~
| | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | LLEI Length | My LLEI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-~
~ | AttrCount | ~
| | LLEI Length | My LLEI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Attribute List ... | Auth Type | Key Length ~
| | AttrCount | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Key ... |
| Attribute List ... | Auth Type | Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Key ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@ -851,13 +851,38 @@ q-->
authentication failures and retries. A configurable failure count
limit (default 8) SHOULD result in giving up on the connection
attempt.</t>
<t>The Serial Number is a monotonically increasing 32-bit value
representing the sender's state at the time of sending the last PDU.
It may be an integer, a timestamp, etc. If incrementing the Serial
Number would cause it to be zero, it should be incremented
again.</t>
<t>The Serial Number is that of the last received and processed PDU.
This allows a receiver sending an OPEN to tell the sender that the
receiver wants to resume a session and the sender only needs to send
data more recent than the Serial Number. If this OPEN is not trying
to restart a lost session, the Serial Number MUST BE set to
zero.</t>
<t>On session restart (new OPEN), a receiver MAY send the last
received Serial Number to tell the sender to only send data with a
Serial Number greater (in the <xref target="RFC1982"/> sense), or
send a Seerial Number of zero to request all data.</t>
<t>The Serial Number supports session resumption in anticipation of
peers having a very large amount of state they would prefer not to
re-exchange because of some glitch. The Serial Number is not
expected to wrap for a considerable time, e.g. days or weeks. But
to address the rare case it does, <xref target="RFC1982"/> on DNS
Serial Number Arithmetic should be used as it is in the Transmission
Sequence Number.</t>
<t>This allows a sender of an OPEN to tell the receiver that the
sender would like to resume a session and that the receiver only
needs to send data starting with the PDU with the lowest Serial
Number greater (in the <xref target="RFC1982"/> sense) than the one
sent in the OPEN. If the sender is not trying to resume a dropped
session, the Serial Number MUST be zero.</t>
<t>If the receiver of an OPEN PDU with a non-zero Serial Number can
not resume from the requested point, it should return an ACK with an
Error Code of 2, Session could not be continued. The sender of the
failing OPEN PDU SHOULD then send an OPEN PDU with a Serial Number
of zero.</t>
<t>The Signature fields are described in <xref target="tlv"/> and in
an asymmetric key environment serve as a proof of possession of the
@ -878,18 +903,18 @@ q-->
new Nonce from an LLEI, speaker B, with which A believes it already
has an L3DL session (OPENs have already been exchanged), and the
Serial Number in the OPEN PDU is non-zero, speaker A SHOULD
establish a new session by sending an OPEN with the Serial Number
being the same as that of A's last sent and ACKed PDU. Each party
MUST resume sending encapsulations etc. subsequent to the other
party's Sequence Number. And each MUST retain all previously
discovered encapsulation and other data.</t>
establish a new sending session by sending an OPEN with the Serial
Number being the same as that of A's last sent and ACKed PDU. A
MUST resume sending encapsulations etc. subsequent to the requested
Sequence Number. And B MUST retain all previously discovered
encapsulation and other data received from A.</t>
<t>If a properly authenticated OPEN arrives with a new Nonce from an
LLEI with which the receiving logical link endpoint believes it
already has an L3DL session (OPENs have already been exchanged), and
the Serial Number in the OPEN is zero, then the receiver MUST assume
that the sending LLEI or entire device has been reset. All
previously discovered encapsulation data MUST NOT be kept and MUST
Previously discovered encapsulation data MUST NOT be kept and MUST
BE withdrawn via the BGP-LS API and the recipient MUST respond with
a new OPEN.</t>
@ -1696,20 +1721,20 @@ q-->
<back>
<references title="Normative References">
<?rfc include="reference.RFC.1213"?>
<?rfc include="reference.RFC.1629"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3032"?>
<?rfc include="reference.RFC.4271"?>
<?rfc include="reference.I-D.ietf-lsvr-bgp-spf"?>
<?rfc include="reference.RFC.5226"?>
<?rfc include="reference.RFC.5880"?>
<?rfc include="reference.RFC.6286"?>
<?rfc include="reference.RFC.7752"?>
<?rfc include="reference.RFC.8174"?>
<?rfc include="reference.I-D.ietf-idr-bgpls-segment-routing-epe"?>
<?rfc include="reference.I-D.ietf-idr-bgp-ls-segment-routing-ext"?>
<?rfc include="reference.I-D.ymbk-lsvr-l3dl-signing"?>
<?rfc include="reference.RFC.1213.xml"?>
<?rfc include="reference.RFC.1629.xml"?>
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.3032.xml"?>
<?rfc include="reference.RFC.4271.xml"?>
<?rfc include="reference.I-D.ietf-lsvr-bgp-spf.xml"?>
<?rfc include="reference.RFC.5226.xml"?>
<?rfc include="reference.RFC.5880.xml"?>
<?rfc include="reference.RFC.6286.xml"?>
<?rfc include="reference.RFC.7752.xml"?>
<?rfc include="reference.RFC.8174.xml"?>
<?rfc include="reference.I-D.ietf-idr-bgpls-segment-routing-epe.xml"?>
<?rfc include="reference.I-D.ietf-idr-bgp-ls-segment-routing-ext.xml"?>
<?rfc include="reference.I-D.ymbk-lsvr-l3dl-signing.xml"?>
<reference anchor="IANA-PEN" target="https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers">
<front>
<title>IANA Private Enterprise Numbers</title>
@ -1744,10 +1769,10 @@ q-->
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0791"?>
<?rfc include="reference.RFC.1122"?>
<?rfc include="reference.RFC.1982"?>
<?rfc include="reference.I-D.malhotra-bess-evpn-lsoe"?>
<?rfc include="reference.RFC.0791.xml"?>
<?rfc include="reference.RFC.1122.xml"?>
<?rfc include="reference.RFC.1982.xml"?>
<?rfc include="reference.I-D.malhotra-bess-evpn-lsoe.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-doi/reference.DOI.10.1145/2975159.xml?anchor=JUPITER"?>
<reference anchor="Clos0" >
<front>