Subject: [tram] I-D Action: draft-ietf-tram-stunbis-04.txt

From: [email-masked]
Date: Fri, 27 Mar 2015 00:55:39 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the TURN Revised and Modernized Working Group of the IETF.

        Title           : Session Traversal Utilities for NAT (STUN)
        Authors         : Marc Petit-Huguenin
                          Gonzalo Salgueiro
                          Jonathan Rosenberg
                          Dan Wing
                          Rohan Mahy
                          Philip Matthews
	Filename        : draft-ietf-tram-stunbis-04.txt
	Pages           : 55
	Date            : 2015-03-27

Abstract:
   Session Traversal Utilities for NAT (STUN) is a protocol that serves
   as a tool for other protocols in dealing with Network Address
   Translator (NAT) traversal.  It can be used by an endpoint to
   determine the IP address and port allocated to it by a NAT.  It can
   also be used to check connectivity between two endpoints, and as a
   keep-alive protocol to maintain NAT bindings.  STUN works with many
   existing NATs, and does not require any special behavior from them.

   STUN is not a NAT traversal solution by itself.  Rather, it is a tool
   to be used in the context of a NAT traversal solution.

   This document obsoletes RFC 5389.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tram-stunbis-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 31 Mar 2015 06:42:08 -0600

Changelog:

o  Remove SCTP.
o  Remove DANE.
o  s/MESSAGE-INTEGRITY2/MESSAGE-INTEGRITY-SHA256/
o  Remove Salted SHA256 password hash.
o  The RTO delay between transactions is removed.
o  Make clear that reusing NONCE will trigger a wasted round trip.

Remaining TODO list:

1.  Add reference to RFC 5769 (stun vectors).
2.  Add flow diagram for long-term authentication.
3.  Add vectors for SHA256 password hash.

> ftp://ftp.ietf.org/internet-drafts/

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Justin Uberti <[email-masked]>
Date: Tue, 31 Mar 2015 12:43:30 -0700

Especially for short-term auth, do we need to send the entire 256-bit MAC?
I am concerned that some implementations will be slow to switch to stun-bis
because of the increased size (and thereby bandwidth) needed for
connectivity checks.

Would it make sense to allow use of a truncated SHA-256 MAC (e.g. 80 bits
or less), similar to how this is done in SRTP?

On Tue, Mar 31, 2015 at 5:42 AM, Marc Petit-Huguenin <[email-masked]>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Changelog:
>
> o  Remove SCTP.
> o  Remove DANE.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJVGpYgAAoJECnERZXWan7EQxUQAJb3cerMgz+k34+9ms3eXwVd
> vaLxOY4jla7j9Gf4O9Xmyd0wKo3VgG9xnfeil95Y/hBMkoIgiwC1iRMEJT0hH9jO
> fe4ekjjuO81wuPyiGOJA7CvsM+dKqc9Y3v+KE43SbYkgoFS12U2m/+0u+emdT4lJ
> olbAnJhl3s6+XCH1HqaSd1S7LGl3f2y1eHPLxkvpLQXZFyHZYJo1JNt0yKR/UZWu
> JJauXVMMqlVMjauAiY7eWOlNOpM15a7+YZ7ShED/eTForBwWyOMfcqZ+kk1at8Fi
> b4XfN+bHOvotoxgJ9myZZvlkMZwmne/XGLkr9HIQgJGMYlbattLpAEoaDApBnxKx
> HYQhl9VECis4TGxUWPSvHgoIP6tHxpomSJ1eD0XDzqqad1ZWqK8OsTy8NZdLgK1n
> H0xaz5QVPaB8k2uVvcmGwzKdsIfUbkFQudTjV8FuuSobsh7QeLL50o8oFdABW/1g
> 201Z7aPmYsseti4JGKpCO5j9VNxjNTxbB3XaAketkRA8afHAUuR8JMFUFLi4Rinv
> MJLaOaKciFfWrBo1FqqoGCqoy7dC8+UN3LFx6Nn9ygpNZt/n8cVNVniRk4hYkbi0
> XOmIzvWtLURupJSr/Wo29K0gsmKJq2MWOK5TFxEyer9i0fArH5W7H8ueirtvWwgc
> vH8+lFtAOQSjokR/eUhT
> =/KmB
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>