jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-tls-dtls-rrc

Commentary: /cc Signed - off - by :   
 This is important and so the example should show it . 
 The draft splits the probes in and . The example demonstrates the so I think , we should add that to the figure description " Basic Return Routability Example " .
The example TLS 1.3 handshake shown in fig-handshake shows a client
and a server negotiating the support for CID and for the RRC
extension.
Once a connection has been established the client and the server
exchange application payloads protected by DTLS with an unilaterally
used CIDs.  In our case, the client is requested to use CID 100 for
records sent to the server.
At some point in the communication interaction the IP address used by
the client changes and, thanks to the CID usage, the security context
to interpret the record is successfully located by the server.
However, the server wants to test the reachability of the client at
his new IP address.
In the example TLS 1.3 handshake shown in fig-handshake, a client and
a server successfully negotiate support for CID as well as the RRC
extension.
Once a connection has been established the client and the server
exchange application payloads protected by DTLS with a unilaterally
used CID.  In our case, the client is requested to use CID 100 for
records sent to the server.
At some point in the communication interaction the IP address used by
the client changes and, thanks to the CID usage, the security context
to interpret the record is successfully located by the server.
However, the server wants to test the reachability of the client at
its new IP address.
fig-rrc-example shows the server initiating a "basic" RRC exchange
(see regular) that establishes reachability of the client at the new
IP address.
Draft: draft-ietf-tls-dtls-rrc

Commentary: /cc Signed - off - by :   
 In this second paragraph , does this mean T=1s or RTT=1s ? 
 FMPOV : ( because that refers to the default timeout of DTLS 1.2 RFC6347 )
If an implementation has no way to obtain information regarding the
RTT of the active path, a value of 1s SHOULD be used.
If an implementation has no way to obtain information regarding the
RTT of the active path, T SHOULD be set to 1s.
Draft: draft-ietf-tls-dtls-rrc

Commentary: Signed - off - by :   
 Also , remove who 's now a co - author .
We would like to thank Hanno Becker,
Draft: draft-ietf-tls-dtls-rrc

Commentary: Signed - off - by :   
 cc 
 works for me 
 For me the is misleading . My understanding was , that RFC9146 recommend to not update the association before passing the address check . So , for me " currently " may be the better choice .
RRC offers an in-protocol mechanism to perform peer address
validation, thus complementing the "peer address update" procedure
described in RFC9146.  Specifically, when both CID RFC9146 and RRC
have been successfully negotiated for the session, if a record with
CID is received that has the source address of the enclosing UDP
datagram different from the one previously associated with that CID
value, the receiver SHOULD perform a return routability check as
described in path-validation, unless an application layer specific
address validation mechanism can be triggered instead.
RRC offers an in-protocol mechanism to perform peer address
validation, thus complementing the "peer address update" procedure
described in RFC9146.  Specifically, when both CID RFC9146 and RRC
have been successfully negotiated for the session, if a record with
CID is received that has the source address of the enclosing UDP
datagram different from the one currently associated with that CID
value, the receiver SHOULD perform a return routability check as
described in path-validation, unless an application layer specific
address validation mechanism can be triggered instead.
Draft: draft-ietf-tls-dtls-rrc

Commentary: Signed - off - by :
The peer endpoint, after successfully verifying the received
"return_routability_check" message responds by echoing the cookie
value in a "return_routability_check" message of type
"path_response".
When the initiator receives the "return_routability_check" message
and verifies that it contains the sent cookie, it updates the peer
address binding.
The peer endpoint cryptographically verifies the received
"return_routability_check" message of type "path_challenge" and
responds by echoing the cookie value in a
"return_routability_check" message of type "path_response".
When the initiator receives the "return_routability_check" message
of type "path_response" and verifies that it contains the sent
cookie, it updates the peer address binding.
Draft: draft-ietf-tls-dtls-rrc

Commentary: Signed - off - by :   
 cc 
 Works for me . 
 What are the considerations about that select ? For me it looks like all " cases " are the same ? Do I oversee something ? 
 Maybe the idea of that select is a " future extension " . If so , " ignore unknown values " includes , to skip what ever follows , or ? Then maybe 
 Yep , exactly : RRC is not closed ( see ) so the select anticipates extensions that might need a value different from Cookie . 
 Thanks .  about the extended formulation : 
 I think the current text is already saying what you propose :-) In the context of the paragraph , there is no " rest of the RRC message " that is n't the " unknown value " , so the addition seems redundant to me .  ? 
 Assuming : If is unknown , what is then to be ignored ? Maybe : 
 This is exactly what I wanted the current text to say . Apparently I failed :-) I 'll do the suggested tweak .
Future extensions or additions to the Return Routability Check
protocol may define new message types.  Implementations MUST be able
to parse and ignore unknown values.
Future extensions or additions to the Return Routability Check
protocol may define new message types.  Implementations MUST be able
to parse and ignore messages with an unknown "msg_type".
Draft: draft-ietf-tls-dtls-rrc

Commentary: Signed - off - by :   
 cc 
 Works for me . 
 When discussing that in RFC9146 , my consideration was , that a " similar mechanism " maybe used also on the next layer . With that , I would consider 
 Just to mention , for me the idea of UDP is : Do , what could be done , but be also open , to delegate functions to the next layer , if it could be done there maybe more efficient . Therefore RRC with DTLS is great as one option , but other options in upper layers should not be discredited .
RRC offers an in-protocol mechanism to perform peer address
validation, thus complementing the "peer address update" procedure
described in RFC9146.  Specifically, when both CID RFC9146 and RRC
have been successfully negotiated for the session, if a record with
CID is received that has the source address of the enclosing UDP
datagram different from the one previously associated with that CID
value, the receiver SHOULD perform a return routability check as
described in path-validation.
RRC offers an in-protocol mechanism to perform peer address
validation, thus complementing the "peer address update" procedure
described in RFC9146.  Specifically, when both CID RFC9146 and RRC
have been successfully negotiated for the session, if a record with
CID is received that has the source address of the enclosing UDP
datagram different from the one previously associated with that CID
value, the receiver SHOULD perform a return routability check as
described in path-validation, unless an application layer specific
address validation mechanism can be triggered instead.
Draft: draft-ietf-tls-dtls-rrc

Commentary: Signed - off - by :   
 CC 
 We do n't currently discuss any privacy implication associated with CID reuse . We should at least : how to ensure a new CID is used during path validation in 1.3 that 1.2 has no way to work around linkability because CID have the same lifetime as the session
When using DTLS 1.3, peers SHOULD avoid using the same CID on
multiple network paths, in particular when initiating connection
migration or when probing a new network path, as described in path-
validation, as an adversary can otherwise correlate the communication
interaction across those different paths.  DTLS 1.3 provides
mechanisms to ensure that a new CID can always be used.  In general,
an endpoint should proactively send a RequestConnectionId message to
ask for new CIDs as soon as the pool of spare CIDs is depleted (or
goes below a threshold).  Also, in case a peer might have exhausted
available CIDs, a migrating endpoint could include NewConnectionId in
packets sent on the new path to make sure that the subsequent path
validation can use fresh CIDs.
Note that DTLS 1.2 does not offer the ability to request new CIDs
during the session lifetime since CIDs have the same life-span of the
connection.  Therefore, deployments that use DTLS in multihoming
environments SHOULD refuse to use CIDs with DTLS 1.2 and switch to
DTLS 1.3 if the correlation privacy threat is a concern.
Draft: draft-ietf-tls-dtls-rrc

Commentary: fix / improve the " attacker model " section Signed - off - by :   
 CC 
 At the top of the " Attacker model " section we say : " RRC is not designed to counter on - path attackers . " What we should say instead is " RRC is not designed to counter man - in - the - middle attackers . " We do take care of on - path attackers , via the challenge / response exchange , and we should say that . 
 I do n't think the CR exchange solves the problem , because the attacker can just change the IP addresses .
RRC is not designed to counter on-path attackers.  These can never be
distinguished from, for example, a genuine network device.  However,
RRC can withstand off-path attackers of the type described below when
the enhanced path validation algorithm (enhanced) is used.
Off-path attackers that try to put themselves on-path (off-path) -
provided that the enhanced path validation algorithm is used, see
enhanced.
An on-path attacker could make a copy of a packet, replace the source
address with a spoofed one and forward it to the original
destination.  If the spoofed packet arrives before the original it
will be regarded as a migration, while the original packet will be
flagged as a duplicate and dropped.
The subsequent path validation (path-validation) will fail because
the entity at the (spoofed) source address does not have the
cryptographic keys needed to decode the "path_challenge" message that
is sent to it, and therefore to produce the corresponding
"path_response".  Since the path validation fails, the address
binding is not altered, thus thwarting the attack.
Draft: draft-ietf-tls-dtls-rrc

Commentary: Signed - off - by :   
 We say : " The initiator MUST silently discard any invalid pathresponse it receives . " we should say instead : " The initiator MUST silently discard any invalid pathresponse or pathdrop it receives . " _
The initiator MUST silently discard any invalid "path_response" it
receives.
The initiator MUST silently discard any invalid "path_response" or
"path_drop" it receives.
Draft: draft-ietf-tls-dtls-rrc

Commentary: factor out common text remove the spurious " address confirmation failure " : path validation only fails on timeout provide further rationale for choosing between basic and enhanced 
 We probably need to tell implementers why / when they should choose the basic algorithm vs the enhanced . For example , avoid enhanced if : you need to minimise implementation complexity you have privacy concerns -- i.e. , to avoid providing a clear correlation signal off - path attackers are not in your threat model and/or you want to reduce the time it takes to switch path 
 In the path validation algorithm ( both base and enhanced ) we say " [ ... ] or the address confirmation fails [ ... ] " , but we do n't say precisely what we mean by that . If it refers to failure in validating the received Cookie value , than there 's a potential out - of - sync with the requirement : " [ ... ] the initiator MUST silently discard any invalid path_response it receives . " If not , we should say what we mean by " address confirmation failure . "
Note: This algorithm does not take the off-path scenario into
account.
The receiver that observes the peer's address or port update MUST
stop sending any buffered application data, or limit the data sent to
the unvalidated address to the anti-amplification limit.
It then initiates the return routability check that proceeds as
described either in enhanced or regular, depending on whether the
off-path attacker scenario described in off-path is to be taken into
account or not.
When the initiator receives and verifies the
"return_routability_check" message contains the sent cookie, it
updates the peer address binding.
If T expires, or the address confirmation fails, the peer address
binding is not updated.
After this point, any pending send operation is resumed to the bound
peer address.
Note: This algorithm also takes the off-path scenario into account.
When the initiator receives the "return_routability_check" message
and verifies that it contains the sent cookie, it updates the peer
address binding.
If T expires the peer address binding is not updated.
If T expires, or the address confirmation fails, the peer address
binding is not updated.  In this case, the initiator MUST perform
a return routability check on the observed new address, as
described in regular.
If T expires the peer address binding is not updated.  In this
case, the initiator MUST perform a return routability check on the
observed new address, as described in regular.
Draft: draft-ietf-tls-dtls-rrc

Commentary: Section 5 title " Off - path packet forwarding " should be " Attack model " instead ? Also , is this the right position ? ISTM this should go after we discuss the base challenge / response mechanics . There is also a missing premise , I think : " RRC is not designed to counter on - path attackers . These can never be distinguished from , for example , a genuine network device . However , RRC can resist off - path attackers when enhanced path validation ( { { enhanced } } ) is used . "
RRC is not designed to counter on-path attackers.  These can never be
distinguished from, for example, a genuine network device.  However,
RRC can withstand off-path attackers of the type described below when
the enhanced path validation algorithm (enhanced) is used.
Draft: draft-ietf-tls-dtls-rrc

Commentary: Section 4 should only provide a description of the RRC messages ( chal / resp & delete ) and say a few words about extensibility of the feature . I think the discussion around interplay between RRC and CID should go in a separate ( sub)section .
When a record with CID is received that has the source address of the
enclosing UDP datagram different from the one previously associated
with that CID, the receiver MUST NOT update its view of the peer's IP
address and port number with the source specified in the UDP datagram
before cryptographically validating the enclosed record(s) but
instead perform a return routability check.
The cookie is a 8-byte field containing arbitrary data.
This document defines the "return_routability_check" content type
(fig-rrc-msg) to carry Return Routability Check protocol messages.
The protocol consists of three message types: "path_challenge",
"path_response" and "path_drop" that are used for path validation and
selection as described in path-validation.
Each message carries a Cookie, a 8-byte field containing arbitrary
data.
Future extensions or additions to the Return Routability Check
protocol may define new message types.  Implementations MUST be able
to parse and ignore unknown values.
RRC offers an in-protocol mechanism to perform peer address
validation, thus complementing the "peer address update" procedure
described in RFC9146.  Specifically, when both CID RFC9146 and RRC
have been successfully negotiated for the session, if a record with
CID is received that has the source address of the enclosing UDP
datagram different from the one previously associated with that CID
value, the receiver SHOULD perform a return routability check as
described in path-validation.
Draft: draft-ietf-tls-dtls-rrc

Commentary: This PR is on top of 
 We probably need to create a new IANA registry for RRC message types . The registry should be initialised with the 3 message types we define in the draft . 
 Ok .
IANA is requested to create a new sub-registry for RRC Message Types
in the TLS Parameters registry IANA.tls-parameters, with the policy
"expert review" RFC8126.
Draft: draft-ietf-tls-dtls-rrc

Commentary: Signed - off - by :   
 A better name could be or -- one does n't " delete " a path . 
 I agree . I prefer path_drop
This case is shown in fig-old-path-not-preferred whereby the sender
replies with a "path_delete" message (2) on the old path.  This
triggers the receiver to send a "path_challenge" (3) on the new path.
The sender will reply with a "path_response" (4) on the new path,
thus providing confirmation for the path migration.
This case is shown in fig-old-path-not-preferred whereby the sender
replies with a "path_drop" message (2) on the old path.  This
triggers the receiver to send a "path_challenge" (3) on the new path.
The sender will reply with a "path_response" (4) on the new path,
thus providing confirmation for the path migration.
If the path through which the message was received is not
preferred, a "return_routability_check" message of type
"path_delete" MUST be returned.  In either case, the peer
endpoint echoes the cookie value in the response.
If the path through which the message was received is not
preferred, a "return_routability_check" message of type
"path_drop" MUST be returned.  In either case, the peer
endpoint echoes the cookie value in the response.
When a "return_routability_check" message of type "path_delete"
was received, the initiator MUST perform a return routability
check on the observed new address, as described in regular.
When a "return_routability_check" message of type "path_drop"
was received, the initiator MUST perform a return routability
check on the observed new address, as described in regular.
The responder MUST NOT delay sending an elicited "path_response"
or "path_delete" messages.
The responder MUST send exactly one "path_response" or
"path_delete" message for each received "path_challenge".
The responder MUST send the "path_response" or the "path_delete"
on the path where the corresponding "path_challenge" has been
received, so that validation succeeds only if the path is
functional in both directions.  The initiator MUST NOT enforce
this behaviour.
The responder MUST NOT delay sending an elicited "path_response"
or "path_drop" messages.
The responder MUST send exactly one "path_response" or "path_drop"
message for each received "path_challenge".
The responder MUST send the "path_response" or the "path_drop" on
the path where the corresponding "path_challenge" has been
received, so that validation succeeds only if the path is
functional in both directions.  The initiator MUST NOT enforce
this behaviour.
Draft: draft-ietf-tls-dtls-rrc

Commentary: Use a new extension type instead . 
 Yes , if tls - flags are not usable for DTLS 1.2 , then go with this . 
 We 'd like to use to negotiate RRC . At the moment , the document seems to be defined for ( D)TLS 1.3 only , but the reason why the same scheme would not be applicable to 1.2 are not fully clear . For now ( -01 ) , optimistically , we are using it in a version agnostic fashion , hoping that eventually that will be the case . Achim has opened an . This issue is for tracking on the RRC side .
This specification uses the tls_flags extension defined in I-D.ietf-
tls-tlsflags to allow a client and a server to negotiate support for
this extension.
The RRC flag is assigned the value (TBD1) and is used in the
ClientHello (CH) and the ServerHello (SH).
The use of RRC is negotiated via the "rrc" DTLS-only extension.  On
connecting, the client includes the "rrc" extension in its
ClientHello if it wishes to use RRC.  If the server is capable of
meeting this requirement, it responds with a "rrc" extension in its
ServerHello.  The "extension_type" value for this extension is TBD1
and the "extension_data" field of this extension is empty.  The
client and server MUST NOT use RRC unless both sides have
successfully exchanged "rrc" extensions.
Note that the RRC extension applies to both DTLS 1.2 and DTLS 1.3.
The newly introduced return_routability_check message contains a
cookie.  The cookie is a 8-byte field containing arbitrary data.
The return_routability_check message MUST be authenticated and
encrypted using the currently active security context.
The newly introduced "return_routability_check" message contains a
cookie.  The cookie is a 8-byte field containing arbitrary data.
The "return_routability_check" message MUST be authenticated and
encrypted using the currently active security context.
IANA is requested to allocate an entry to the TLS "ContentType"
registry, for the return_routability_check(TBD) defined in this
document.
IANA is requested to allocate an entry to the TLS "ContentType"
registry, for the "return_routability_check(TBD2)" defined in this
document.  The "return_routability_check" content type is only
applicable to DTLS 1.2 and 1.3.
IANA is requested to allocate the extension code point (TBD1) for the
"rrc" extension to the "TLS ExtensionType Values" registry as
described in tbl-ext.
Draft: draft-ietf-tls-dtls-rrc

Commentary: explicit challenge / response messages fixed size 8 byte cookie allow future extensibility of the message types
The newly introduced return_routability_check message contains a
cookie.  The semantic of the cookie is similar to the cookie used in
the HelloRetryRequest message defined in RFC8446.
The newly introduced return_routability_check message contains a
cookie.  The cookie is a 8-byte field containing arbitrary data.
Draft: draft-ietf-tls-dtls-rrc

Commentary: Updated draft based on feedback from the working group . The following changes have been made : Usage of the TLS flags extension Enhanced IANA consideration section Expanded example section 
 a few inline suggestions
This specification uses the tls_flags extension defined in I-D.-ietf-
tls-tlsflags to allow a client and a server to negotiate support for
this extension.
The RRC flag is assigned the value (TBD1) and is used in the
ClientHello (CH) and the ServerHello (SH).
The example shown in fig-rrc-example illustrates a client and a
server exchanging application payloads protected by DTLS with an
unilaterally used CIDs.  At some point in the communication
interaction the IP address used by the client changes and, thanks to
the CID usage, the security context to interpret the record is
successfully located by the server.  However, the server wants to
test the reachability of the client at his new IP address, to avoid
being abused (e.g., as an amplifier) by an attacker impersonating the
client.
The example TLS 1.3 handshake shown in fig-handshake shows a client
and a server negotiating the support for CID and for the RRC
extension.
Once a connection has been established the client and the server
exchange application payloads protected by DTLS with an unilaterally
used CIDs.  In our case, the client is requested to use CID 100 for
records sent to the server.
At some point in the communication interaction the IP address used by
the client changes and, thanks to the CID usage, the security context
to interpret the record is successfully located by the server.
However, the server wants to test the reachability of the client at
his new IP address.
IANA is requested to allocate an entry to the existing TLS
"ContentType" registry, for the return_routability_check(TBD) defined
in this document.
IANA is requested to allocate an entry to the TLS "ContentType"
registry, for the return_routability_check(TBD) defined in this
document.