Subject: [SAFE] nat-control-stun-usage-03

From: "Dan Wing" <[email-masked]>
Date: Wed, 11 Jul 2007 17:32:16 -0700

FYI, a new version was posted yesterday.

Changes between -03 and 02:

   o  Removed TLS from normal STUN operation (as few use it, and ICE
      makes it unnecessary anyway)

   o  BOOTNONCE attribute replaces STUN Control's previous use of TLS.

   o  Added "MIP-capable" bit to TAG attribute

   o  Removed "inside-out" discovery technique.

Comments welcome.  See you in Chicago.

-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, July 10, 2007 11:15 AM
> To: [email-masked]
> Subject: I-D ACTION:draft-wing-behave-nat-control-stun-usage-03.txt 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: Discovering, Querying, and 
> Controlling Firewalls and NATs using STUN
> 	Author(s)	: D. Wing, et al.
> 	Filename	: 
> draft-wing-behave-nat-control-stun-usage-03.txt
> 	Pages		: 27
> 	Date		: 2007-7-10
> 	
> Simple Traversal Underneath NAT (STUN) is a mechanism for traversing
>    NATs.  STUN requests are transmitted through a NAT to external STUN
>    servers.  While this works very well, its two primary drawbacks are
>    the inability to modify the properties of a NAT binding 
> and the need
>    to query a public STUN server for every new NAT binding 
> (e.g., every
>    phone call).  These drawbacks require frequent messages 
> which present    a load on servers (like SIP servers and STUN 
> servers) and are bad for
>    low speed access networks, such as cellular access.
> 
>    This document describes two mechanisms to discover NATs 
> and firewalls
>    and a mechanism to query and control them.  With these mechanisms,
>    binding discovery and keepalive traffic can be reduced to involve
>    only the necessary NATs or firewalls.  At the same time, backwards
>    compatibility with NATs and firewalls that do not support this
>    document is retained, which allows for incremental deployment of
>    these mechanisms.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-wing-behave-nat-cont
> rol-stun-usage-03.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in 
> the body of 
> the message. 
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-wing-behave-nat-control-stun-usage-03.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE 
> /internet-drafts/draft-wing-behave-nat-control-stun-usage-03.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

_______________________________________________
SAFE mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/safe

---

From: Philip Matthews <[email-masked]>
Date: Fri, 13 Jul 2007 15:37:43 -0400

Two comments on this document.

1) Why must the TAG attribute be placed as the last attribute in the  
message? There is a lot of competition for the "last attribute" spot  
these days: MESSAGE-INTEGRITY, then FINGERPRINT, and now TAG. What if  
the message contains both a FINGERPRINT and a TAG attribute?

2) We should probably recommend a default maximum refresh-interval.  
Perhaps 2 hours. That is, if a client requests 47 days, it only gets  
2 hours. 47 days is pretty extreme.

Also, I didn't see the "MIP-capable" bit mentioned below.

- Philip

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 13 Jul 2007 12:48:45 -0700

> From: Philip Matthews [mailto:[email-masked]] 
> Sent: Friday, July 13, 2007 12:38 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [SAFE] nat-control-stun-usage-03
> 

Thanks for your review.

> message?

It can't be before the MESSAGE-INTEGRITY, because that attribute
protects all attributes before it, and the firewall doesn't know the
secret used to build the Message-Integrity.

> There is a lot of competition for the "last attribute" spot  

It wouldn't matter which went last -- what matters to TAG is that
it doesn't get added before MESSAGE-INTEGRITY.

I have adjusted the text in my working copy to read:

  ... MUST append this attribute after the MESSAGE-INTEGRITY 
  attribute ...

> 2 hours. 47 days is pretty extreme.

Sure.

> Also, I didn't see the "MIP-capable" bit mentioned below.

Section 6.4:

   The one-bit M field indicates if this firewall permits Mobility
   Header packets to flow through it ([RFC3775]).

I added "MIP" to that reference in my working copy.

-d

> >>    servers.  While this works very well, its two primary 
> drawbacks  
> >> are