Hi,
Should "return_routability_check" use flight retransmission [1] ?
Should the heartbeat message be re-used instead of the proposed new
message exchange?
It sounds really similar, except that if heartbeat failed we
terminate the connection and for "return_routability_check" we update
the peer address.
Must heartbeat message be authenticated and encrypted using the
currently active security context ? reading the RFC[2] it's not clear to me.
heartbeat RFC also explains how to handle heartbeat message during
handshake. Maybe this RFC should clarify this too.
Simon
[1] https://tools.ietf.org/html/rfc6347#section-4.2.4
[2] https://tools.ietf.org/html/rfc6520
Le 09/07/2019 à 11:05, Hannes Tschofenig a écrit :
Hi all,
working on the DTLS connection id drafts we noticed that there is one
security aspect, which could benefit from an extra mitigation technique.
The issue is that an on-path adversary could intercept and modify the
source IP address (and the source port) of a DTLS datagram. Even if
receiver checks the authenticity and freshness of the packet, the
recipient is fooled into changing the CID-to-IP/port association. This
can lead to black-holed or redirected traffic. Of course, an on-path
adversary can do lots of things to traffic and the problem is
self-fixing but it still lead us to work on a solution in form of a
return-routability check.
Here is the draft:
https://tools.ietf.org/html/draft-tschofenig-tls-dtls-rrc-00
Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose
the contents to any other person, use it for any purpose, or store or
copy the information in any medium. Thank you.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
