Hi Eric,
> ### 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?
RRC is a "companion extension" for DTLS CID, and DTLS CID was introduced
to mitigate address remapping (e.g. caused by NAT timeouts).
In the very most cases, if the server gets a message with an new
address, this is no indication of an attack, this is the usual and
expected behavior. Using the old path, especially if that was used
"longer" ago (I use 30s as "longer") doesn't make too much sense,
because that will then be withdrawn/dropped by the NAT.
If a response is larger (see definition of amplification), using RRC
with small messages in order to check the new path is something I would
always recommend.
Checking the old path I would only do, if I'm aware of the specific
network setup (e.g. defined and known NAT timeout) and so using the
old path has a chance to be successful.
br
Achim
Am 05.07.25 um 01:44 schrieb Erik Kline via Datatracker:
Erik Kline has entered the following ballot position for
draft-ietf-tls-dtls-rrc-18: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/
----------------------------------------------------------------------
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?
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
