Return Routability Check for DTLS 1.2 and DTLS 1.3
draft-ietf-tls-dtls-rrc-20

[Ballot comment]
** From idnits
  -- The draft header indicates that this document updates RFC9146, but the
    abstract doesn't seem to mention this, which it should.

[Ballot discuss]
Hear, hear! My DISCUSS is probably the easiest to address

This document updates RFC9146, but does not seem to include explanatory text
about this in the abstract.

[Ballot comment]
Section 5, paragraph 1
>    This document describes two kinds of checks: basic (Section 5.1) and
>    enhanced (Section 5.2).  The choice of one or the other depends on
>    whether the off-path attacker scenario described in Section 8.1.2 is
>    to be considered.  (The decision on what strategy to choose depends
>    mainly on the threat model, but may also be influenced by other
>    considerations.  Examples of impacting factors include: the need to
>    minimise implementation complexity, privacy concerns, and the need to
>    reduce the time it takes to switch path.  The choice may be offered
>    as a configuration option to the user of the TLS implementation.)

From an operations perspective, the ability for the user to configure the option should be highlighted in a separate section called "Operational Considerations".

The IANA review of this document has not concluded yet.

Check whether Expert Review is an appropriate registration policy here.

Possible DOWNREF from this Standards Track doc to [IANA.tls-parameters]. If so,
the IESG needs to approve it.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Reference [RFC6347] to RFC6347, which was obsoleted by RFC9147 (this may be on
purpose).

[Ballot comment]
Thanks for addressing my previous DISCUSS point (https://mailarchive.ietf.org/arch/msg/tls/EQ0R8r6C_Vmoq3jMa8hx48XlQ20/ ) and most of the COMMENTS below.

Regards

-éric

## COMMENTS (non-blocking)

### FATT process ?

Out of curiosity, I still wonder what `FATT process` and `FATT review` mean in the shepherd write-up.

### Use of "path"

Probably too late to change, but the choice of "path" rather than "anchor" or "socket" (or something else) is poor... the actual path (the set of network links and devices) keeps changing in an IP network.

### Section 1

A small graphical (packet exchange) would be useful even if the text is clear.

### Section 3

What is the expected server behavior when the client sends the rcc extension without offering the connection_id extension ? Is the whole handshake stopped or is the option ignored ? Please be specific.

### Section 4

Probably due to my lack of familiarity with the used syntax, but it seems that the enum part is not really part of the figure 1 legend of `Return Routability Check Message`. It seems more like an addition to TLS Content Type registry. Suggest to split this figure in two figures with 2 distinct legends.

### Section 5

s/has faster routing/has faster forwarding/ ?

### Section 5.1.1

Related to `the original packet still reaches the intended destination`, does this mean that an attacker can prevent rebinding to a new address/port by sending the packet from the 'old' address/port ?

### Section 5.2.1

What is "AP" in figures 5 and 6?

### Section 10.2

As this section ends with a recommendation, should it clearly be in the protocol specification part rather than in operational considerations ?

[Ballot comment]
Thanks for addressing my previous DISCUSS point (draft-ietf-intarea-icmp-exten-hdr-len-01) and most of the COMMENTS below.

Regards

-éric

## COMMENTS (non-blocking)

### FATT process ?

Out of curiosity, I still wonder what `FATT process` and `FATT review` mean in the shepherd write-up.

### Use of "path"

Probably too late to change, but the choice of "path" rather than "anchor" or "socket" (or something else) is poor... the actual path (the set of network links and devices) keeps changing in an IP network.

### Section 1

A small graphical (packet exchange) would be useful even if the text is clear.

### Section 3

What is the expected server behavior when the client sends the rcc extension without offering the connection_id extension ? Is the whole handshake stopped or is the option ignored ? Please be specific.

### Section 4

Probably due to my lack of familiarity with the used syntax, but it seems that the enum part is not really part of the figure 1 legend of `Return Routability Check Message`. It seems more like an addition to TLS Content Type registry. Suggest to split this figure in two figures with 2 distinct legends.

### Section 5

s/has faster routing/has faster forwarding/ ?

### Section 5.1.1

Related to `the original packet still reaches the intended destination`, does this mean that an attacker can prevent rebinding to a new address/port by sending the packet from the 'old' address/port ?

### Section 5.2.1

What is "AP" in figures 5 and 6?

### Section 10.2

As this section ends with a recommendation, should it clearly be in the protocol specification part rather than in operational considerations ?

[Ballot comment]
# Internet AD comments for draft-ietf-tls-dtls-rrc-18
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S6

* A brief explanation of what is meant by "nested rebinding" would be good.

### S6.{2,3,...}

* I think if I were implementing this I would try to probe both the old
  and the new paths at the same time.

  Can you say something about the considerations such an implementation
  would need to be aware of?

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-tls-dtls-rrc-18
CC @evyncke

Thank you for the work put into this document. Thanks for using SVG graphics :-)

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Sean Turner for the shepherd's detailed write-up including the WG consensus (and the 2 WGLC) and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:


### Section 6.2

In the case of NAT rebinding, how can a responder behind a NAT detect that its external address/port has changed as seen by the initiator: it still receives the other peers packet sent to its unchanged address/port ? What am I missing ?

This could probably be addressed by some more text before `The action to be taken depends on whether or not the path through which the message was received is still the preferred one`.

[Ballot comment]

## COMMENTS (non-blocking)

### FATT process ?

Out of curiosity, I still wonder what `FATT process` and `FATT review` mean in the shepherd write-up.

### Use of "path"

Probably too late to change, but the choice of "path" rather than "anchor" or "socket" (or something else) is poor... the actual path (the set of network links and devices) keeps changing in an IP network.

### Section 1

A small graphical (packet exchange) would be useful even if the text is clear.

### Section 3

What is the expected server behavior when the client sends the rcc extension without offering the connection_id extension ? Is the whole handshake stopped or is the option ignored ? Please be specific.

### Section 4

Probably due to my lack of familiarity with the used syntax, but it seems that the enum part is not really part of the figure 1 legend of `Return Routability Check Message`. It seems more like an addition to TLS Content Type registry. Suggest to split this figure in two figures with 2 distinct legends.

### Section 5

s/has faster routing/has faster forwarding/ ?

### Section 5.1.1

Related to `the original packet still reaches the intended destination`, does this mean that an attacker can prevent rebinding to a new address/port by sending the packet from the 'old' address/port ?

### Section 5.2.1

What is "AP" in figures 5 and 6?

### Section 10.2

As this section ends with a recommendation, should it clearly be in the protocol specification part rather than in operational considerations ?

[Ballot comment]
Thanks to Mike Ounsworth for their secdir review.

Section 2, para 3:  The definition of 'anti-amplification limit' is incomplete.  Three times the amount of data received compared to what?  In RFC 9000, the definition is as follows:  "Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit."  I think you need to add '...means limiting data sent to an unvalidated address to three times the amount of data received...'.  [at this point the requirement in Section 6 makes more sense]

Section 5, off-path attacker bullet:  '...copies of the observed packets...', does this mean replay packets? I'm not sure what is more widely understood.  Possibly add a 'copy' or 'replay' row to Figure 2?

Section 8, para 2:  Please reword the last two sentences.  Perhaps something like 'To prevent this,...using a reliable source of entropy.  See Appendix C.1 of RFC 8446 for guidance.'  [Note RFC 4086 is pretty old, most O/S have reasonable RNGs (which is what Appendix C.1 states)]

[Ballot comment]
Thanks for this work. I have no objections to the publication of this document as an RFC. Many thanks to Russ Housley for the ARTART review.

[Ballot comment]
Hi Hannes, Achim, and Thomas,

Thank you for the effort put into this specification.

Thanks to Joe Clarke for the OPSDIR review and Thomas for positively addressing the comment. Much appreciated.

I’m balloting Yes as this is a specification I would be happily sponsoring myself.

There are some few points that I think need some further considerations:

# Should we tag this document as updating RFC9146?

CURRENT:
  A client offering the
  “connection_id” extension SHOULD also offer the rrc extension, unless
  the application using DTLS has its own address validation mechanism.

Although this does not change anything in 9146, this new requirement is worth to be LOUDLY visible for 9146 implementer.

# Deviation or compliance with the QUIC procedure?

## First, having a statement early in the document to say that this procedure is inspired from the RFC9000 connection migration procedure would be fair.

## I’m not sure if we have full adherence with the approach in RFC9000#Section 8.2 or there are deviations. At least, I see that we don’t have here an equivalent to disable_active_migration. Would it be possible please to have a statement whether we deviate or not from 9000 (and of so list those with the motivation for such deviations?).

# Path and address control assumptions

## Path assumptions

For example, Section 5 has the following:

CURRENT:
  For instance, NAT rebinding is improbable if
  packets were recently received on the old path; similarly, rebinding
  is rare on IPv6 paths. 

This puts assumptions on the path that may not be always valid. Also, I would not treat IPv6 as special here because NAT64 may be on-path.

Think about multi-homed address-rewriting devices (multi-homed CPEs with eventually CGNs/NAT64 in all or subset of the network attachment) that use some kind of packet scheduling rather than flow-based to distribute packet among available network attachments. Under such conditions, a client can be seen with distinct addresses. Such scenarios may be possible with UDP. Things are different for TCP, where such mechanisms may be problematic in the presence of firewall (e.g., an on-path stateful device may reject a segment if it didn’t observed a SYN).

## Impossibility to adhere with a MUST

Section 6.2 has the following:

CURRENT:
      *  If the path through which the message was received is no
          longer preferred, a return_routability_check message of type
          path_drop MUST be returned.  In either case, the peer echoes
          the cookie value in the response.

This text (and similar) makes an assumption on address control/path awareness of endpoints, which I think does not stand in many cases.

The external address and forwarding path may not be under the control of the endpoint. It does not even know that the external address changes. Endpoints may use the same local address but distinct external addressed/forwarding paths

## Path control

Section 6.4 has the following:

CURRENT:
  *  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.

Endpoints does not have control on the path. Rather than reasoning on what is beyond their control, may be reason about interface by which a message was received or something this is under the control of an endpoint.

# Broken MUST?

Section 6.4 has the following

CURRENT:
  *  The responder MUST send exactly one path_response or path_drop
      message for each received path_challenge.

This should be applicable only for a valid received challenge message. Please reword.

# Lack of guards against frequent migration and connection oscillation

There might be cases where frequent address changes may be observed. Triggering the validation procedure too frequently may lead to instability. Should there be a guard to control the spacing of migration?

# Detailed comments

## The procedure check in the document is about forwarding, not routing.

## Terminology

### I suggest we grab the definition of “Address” from 9000 and use it through the document.

NEW:
  Address: When used without qualification, the tuple of IP version, IP address, and UDP port number that represents one end of a network path.

### Incomplete list

CURRENT:
  The terms "peer" and "endpoint" are defined in Section 1.1 of
  [RFC8446].

The main text also used “client”. Consider adding it to that list.

## Section 3

CURRENT:
  The client and
  server MUST NOT use RRC unless both sides have successfully exchanged
  rrc extensions.  A client offering the “rrc” extension MUST also offer
  the connection_id extension [RFC9146]. 

Consider reorder to follow the validation logic. I would place the second sentence first.

## Section 5

### I would move this section to be a subsection of the Security Considerations.

### Faster routing?!

CURRENT:
  *  An off-path attacker is not on the original path between the DTLS
      peers, but is able to observe packets on the original path and has
      faster routing compared to the DTLS peers,

I really don’t parse what is meant by faster routing. Please reword/clarify

### Attack types

CURRENT:
              .--> .------------------------------------. <--.
              |    | Inspect un-encrypted portions      |    |
              |    +------------------------------------+    |
              |    | Inject                            |    |
          off-path +------------------------------------+    |
              |    | Reorder                            |    |
              |    +------------------------------------+    |
              |    | Modify un-authenticated portions  | on-path
              '--> +------------------------------------+    |
                  | Delay                              |    |
                  +------------------------------------+    |
                  | Drop                              |    |
                  +------------------------------------+    |
                  | Manipulate the packetization layer |    |
                  '------------------------------------' <--'

                      Figure 2: Attacker capabilities

I would add “store” as an additional line for on-path. That can be used for replay attacks.

## Section 6

### Broken MUST

CURRENT:
  The receiver that observes the peer's address or port number change MUST
  stop sending any buffered application data, or limit the data sent to
  the unvalidated address to the anti-amplification limit. 

This absolute requirement is only valid assuming the extension is successfully validated. Please update accordingly.

Also, s/ The receiver/A receiver

### Hidden Operational Consideration

CURRENT (6):
  (The decision on what strategy to choose depends
  mainly on the threat model, but may also be influenced by other
  considerations.  Examples of impacting factors include: the need to
  minimise implementation complexity, privacy concerns, and the need to
  reduce the time it takes to switch path.  The choice may be offered
  as a configuration option to the user of the TLS implementation.)


CURRENT (6.3):
      -  In general, the number of "backup" path_challenge messages
        depends on the application, since some are more sensitive to
        latency caused by changes in the path than others.  In the
        absence of application-specific requirements, the initiator can
        send a path_challenge message once per round-trip time (RTT),
        up to the anti-amplification limit.

Consider moving this text to be discussed under Operational Consideration section.

### Nested rebinding

CURRENT:
  Please note that the presented algorithms are not designed to handle
  nested rebindings. 

Can we be explicit about the case we are referring to? Is this the case of double NAT, for example? Else?

## Random Data

CURRENT:
  Each path_challenge message MUST contain random data.

Does that random data to be unique per challenge message?

## Section 10

Maybe mention that detection of frequent paths probes is a signal of path instability and that such event can be used to diagnose underlying connectivity service.

## Section 11

### Indicate the registry group

OLD:
  IANA is requested to allocate an entry in the TLS ContentType
  Registry
NEW:
  IANA is requested to allocate an entry in the TLS ContentType
  Registry under the “Transport Layer Security (TLS) Parameters” registry group

### Use the name used by IANA

OLD:
  IANA is requested to create a new registry "RRC Message Types" within
  the TLS Parameters 

NEW:
  IANA is requested to create a new registry "RRC Message Types" within
  the Transport Layer Security (TLS) Parameters

## Misc.

### Section 1:

* s/return routability check (RRC)/Return Routability Check (RRC)

* s/and/or port/and/or port number

* s/address (and port)/address (and port number)


### Section 5

(1)

OLD: We define two classes of attackers

NEW: Two classes of attackers are considered

(2)

OLD: a RRC message

NEW: an RRC message

### Section 7

OLD:
  In the example DTLS 1.3 handshake shown in Figure 7, a client and a
  server successfully negotiate support for both CID and the RRC
  extension.

NEW:
  In the example of DTLS 1.3 handshake shown in Figure 7, a client and a
  server successfully negotiate support for both CID and the RRC
  extensions.

### Section 10

Per the guidance in draft-opsarea-rfc5706bis, it is recommended to put this section right before the security cons section.

### Global

* s/rrc extension/“rrc” extension (idem for other extensions

* s/Return Routability Check sub-protocol/RRC sub-protocol

Hope this helps. 

Cheers,
Med

[Ballot comment]
Section 5.2.1 should describe in more detail that the case where "it is not possible to distinguish between an attack and an improvement in routing" will look different from the viewpoint of Sender and Receiver. Because the attacker is duplicating the Sender's packets from the old address to the new address, the Sender would see the RRC message as a re-validation for the current path and would generate a path-response, believing it is doing what Figure 6 illustrates. However, the attacker will forward this path-response to the Receiver; if it wins the race (or can cause packet loss on the old path), the Receiver will see the path-response message arrive from the new address, not the old.

The behavior as defined in Section 6.2 addresses this by preventing a switch on receipt of a path_response without regard to the path on which it actually arrived. However, if the attacker is able to elicit a response of type path_drop to a given path_challenge, for example by injecting a modified copy of the path_challenge, that can be used to spoof dropping the challenged older path. This may need an additional branch in 6.2 step 3, prohibiting any response if the path where the message was received has never been a preferred path.

In 10.1, consider advising that implementations log when responses to a single path_challenge are received, as this could also be suggestive of an attempt at the above attack.

In 11.2, why is this extension not Recommended for implementations to support? That would seem to say that it either "has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases." While the applicability is limited to DTLS, that is already communicated by the DTLS-Only column.

In 11.3, please fully specify the name of the requested registry. Also, why is a DTLS-Only column needed in a registry which contains messages within a sub-protocol which only exists in DTLS? This restriction could be communicated with a note on the registry or in the title of the registry (e.g. "DTLS Return Routability Check Message Types"). (Obviously retain it if there is future work to support RRC outside of DTLS which will share this registry.)

=== NITS FOLLOW ===

- Section 3.1, "application layer specific" => "application-specific" or "application-layer" should be sufficient

- Figure 7, '*' appears in the key but nowhere in the figure. I assume this is copied from other similar figures which use it, but it can be omitted here.

- Section 7, "our" => "this"

- Section 11.1, "entry to" => "entry in"; remove comma after "registry"

[Ballot discuss]
The RFC 9000 reference is currently informative, used to support the definition of the term "anti-amplification limit" in Section 2. However, conformance with this limit is normatively required in Section 6. Please rephrase Section 2 to include the full definition in this document that is required to understand the normative requirement; RFC 9000 can optionally be retained as an informative reference to a parallel usage, as done in Section 5.  (Alternatively, you could make the RFC 9000 reference normative, but I don't think that's necessary.)

[Ballot comment]
Section 5.2.1 should describe in more detail that the case where "it is not possible to distinguish between an attack and an improvement in routing" will look different from the viewpoint of Sender and Receiver. Because the attacker is duplicating the Sender's packets from the old address to the new address, the Sender would see the RRC message as a re-validation for the current path and would generate a path-response, believing it is doing what Figure 6 illustrates. However, the attacker will forward this path-response to the Receiver; if it wins the race (or can cause packet loss on the old path), the Receiver will see the path-response message arrive from the new address, not the old.

The behavior as defined in Section 6.2 addresses this by preventing a switch on receipt of a path_response without regard to the path on which it actually arrived. However, if the attacker is able to elicit a response of type path_drop to a given path_challenge, for example by injecting a modified copy of the path_challenge, that can be used to spoof dropping the challenged older path. This may need an additional branch in 6.2 step 3, prohibiting any response if the path where the message was received has never been a preferred path.

In 10.1, consider advising that implementations log when responses to a single path_challenge are received, as this could also be suggestive of an attempt at the above attack.

In 11.2, why is this extension not Recommended for implementations to support? That would seem to say that it either "has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases." While the applicability is limited to DTLS, that is already communicated by the DTLS-Only column.

In 11.3, please fully specify the name of the requested registry. Also, why is a DTLS-Only column needed in a registry which contains messages within a sub-protocol which only exists in DTLS? This restriction could be communicated with a note on the registry or in the title of the registry (e.g. "DTLS Return Routability Check Message Types"). (Obviously retain it if there is future work to support RRC outside of DTLS which will share this registry.)

=== NITS FOLLOW ===

- Section 3.1, "application layer specific" => "application-specific" or "application-layer" should be sufficient
- Figure 7, '*' appears in the key but nowhere in the figure. I assume this is copied from other similar figures which use it, but it can be omitted here.
- Section 7, "our" => "this"
- Section 11.1, "entry to" => "entry in"; remove comma after "registry"

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-tls-dtls-rrc-13. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are three actions which we must complete.

First, in the TLS ContentType registry in the Transport Layer Security (TLS) Parameters registry group located at:

https://www.iana.org/assignments/tls-parameters/

the early allocation for:

Value: 27
Description: return_routability_check

is to be made permanent and its reference changed to [ RFC-to-be ]. In addition, a note will be added to the registry as follows:

NOTE: The return_routability_check content type is only applicable to DTLS 1.2 and 1.3.

Second, in the TLS ExtensionType Values registry in the Transport Layer Security (TLS) Extensions registry group located at:

https://www.iana.org/assignments/tls-extensiontype-values/

the early registration for:

Value: 61
Extension Name: rrc
TLS 1.3: CH, SH
DTLS-Only: Y
Recommended: N

will have its reference changed to [ RFC-to-be ].

Third, a new registry is to be created called the RRC Message Types registry. The new registry will be located in the Transport Layer Security (TLS) Parameters registry group located at:

https://www.iana.org/assignments/tls-parameters/

The new registry will be managed via Standards Action as defined in [RFC8126]. There are initial registrations in the new registry as follows:

Value Description DTLS-Only Reference
-----+-----------+----------+-------------
0 path_challenge Y [ RFC-to-be ]
1 path_response Y [ RFC-to-be ]
2 path_drop Y [ RFC-to-be ]
3-253 Unassigned
254-255 Reserved for Private Use Y [ RFC-to-be ]

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-06-10):

From: The IESG
To: IETF-Announce
CC: draft-ietf-tls-dtls-rrc@ietf.org, paul.wouters@aiven.io, sean@sn3rd.com, tls-chairs@ietf.org, tls@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Return Routability Check for DTLS 1.2 and DTLS 1.3) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Return Routability Check for DTLS 1.2 and
DTLS 1.3'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-06-10. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies a return routability check for use in context
  of the Connection ID (CID) construct for the Datagram Transport Layer
  Security (DTLS) protocol versions 1.2 and 1.3.

Discussion Venues

  This note is to be removed before publishing as an RFC.

  Discussion of this document takes place on the Transport Layer
  Security Working Group mailing list (tls@ietf.org), which is archived
  at https://mailarchive.ietf.org/arch/browse/tls/.

  Source for this draft and an issue tracker can be found at
  https://github.com/tlswg/dtls-rrc.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG reached broad consensus on this I-D, at least from those that care about
DTLS. This I-D did go through two WGLCs; the 1st one we didn’t get a lot of
responses, but for the second one we got more.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particular controversies, but because DTLS is a niche protocol as compared
to TLS we did struggle to get reviewers.

NOTE: There were delays in progressing this draft. The 1st was to garner more
reviews. The 2nd was to wait for implementations. The 3rd was for the FATT
process to play out.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

I know of no threat of an appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

We paused this I-D for a bit while we got some implementations. We have two different
clients (Eclipse/Californium & Pion) that interoperate with a server.

Please note that early IANA registrations were made for the content type and extension
type years ago.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. It completed a 2nd WGLC and was awaiting review by the FATT. The FATT’s review
was that it did not need formal analysis; see
https://mailarchive.ietf.org/arch/msg/tls/bsy7kqODax0sxMkedJCUqPPAb64/..

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Note that this has a combined “Security And Privacy Considerations” section that
ID-Nits complains about.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The type requested is Proposed Standard track. This is proper as this draft
documents interoperability between DTLS implementations; where DTLS is Proposed
Standard track. Also, it defines a new TLS Content Type (see s10.1) and that
registration requires “Standards Action”; see:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

I have confirmed with the authors that they have made the necessary disclosures.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

I have confirmed with the authors that are willing to be listed as authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

I-D nits complains about no Security Considerations section, but there is one
it is just combined with the Privacy considerations. There also some weird spacing,
but it’s part of a figure so :shrug:.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

References look fine to me.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

N/A

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

There are informative references to:

* draft-ietf-uta-tls13-iot-profile: Is in WGLC.
* draft-irtf-t2trg-amplification-attacks: :shrug:

Please note that this I-D refers to RFC 8446 and draft-ietf-tls-rfc8446 is on
the 2025-05-22 telechat. This I-D may switch to refer to that I-D during AUTH48.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

N/A

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Note that this I-D creates a new TLS content type; this requires Standard Action.
The return_routability_check content type has been registered since 2023-11-28.
The rrc TLS extension has also been registered since 2023-11-28.

The only thing the draft might do is add a Comment/Comments column to the new
RRC Message Type registry to match what’s going on in draft-ietf-tls-rfc8447bis.
Thomas has already created a PR for this, see:
https://github.com/tlswg/dtls-rrc/pull/75.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG reached broad consensus on this I-D, at least from those that care about
DTLS. This I-D did go through two WGLCs; the 1st one we didn’t get a lot of
responses, but for the second one we got more.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particular controversies, but because DTLS is a niche protocol as compared
to TLS we did struggle to get reviewers.

NOTE: There were delays in progressing this draft. The 1st was to garner more
reviews. The 2nd was to wait for implementations. The 3rd was for the FATT
process to play out.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

I know of no threat of an appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

We paused this I-D for a bit while we got some implementations. We have two different
clients (Eclipse/Californium & Pion) that interoperate with a server.

Please note that early IANA registrations were made for the content type and extension
type years ago.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

N/A

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. It completed a 2nd WGLC and was awaiting review by the FATT. The FATT’s review
was that it did not need formal analysis; see
https://mailarchive.ietf.org/arch/msg/tls/bsy7kqODax0sxMkedJCUqPPAb64/..

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Note that this has a combined “Security And Privacy Considerations” section that
ID-Nits complains about.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The type requested is Proposed Standard track. This is proper as this draft
documents interoperability between DTLS implementations; where DTLS is Proposed
Standard track. Also, it defines a new TLS Content Type (see s10.1) and that
registration requires “Standards Action”; see:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

I have confirmed with the authors that they have made the necessary disclosures.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

I have confirmed with the authors that are willing to be listed as authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

I-D nits complains about no Security Considerations section, but there is one
it is just combined with the Privacy considerations. There also some weird spacing,
but it’s part of a figure so :shrug:.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

References look fine to me.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

N/A

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

There are informative references to:

* draft-ietf-uta-tls13-iot-profile: Is in WGLC.
* draft-irtf-t2trg-amplification-attacks: :shrug:

Please note that this I-D refers to RFC 8446 and draft-ietf-tls-rfc8446 is on
the 2025-05-22 telechat. This I-D may switch to refer to that I-D during AUTH48.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

N/A

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

Note that this I-D creates a new TLS content type; this requires Standard Action.
The return_routability_check content type has been registered since 2023-11-28.
The rrc TLS extension has also been registered since 2023-11-28.

The only thing the draft might do is add a Comment/Comments column to the new
RRC Message Type registry to match what’s going on in draft-ietf-tls-rfc8447bis.
Thomas has already created a PR for this, see:
https://github.com/tlswg/dtls-rrc/pull/75.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/