Subject: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-07.txt

From: [email-masked]
Date: Mon, 09 Jul 2007 00:00:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

        Title           : Session Traversal Utilities for (NAT) (STUN)
        Author(s)       : J. Rosenberg, et al.
        Filename        : draft-ietf-behave-rfc3489bis-07.txt
        Pages           : 46
        Date            : 2007-07-08
                                                                                           
Session Traversal Utilities for NAT (STUN) is a protocol that serves
as a tool for other protocols in dealing with 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 is an
important change from the previous version of this specification (RFC
3489), which presented STUN as a complete solution.
This document obsoletes RFC 3489.
                                                                                           
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.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-ietf-behave-rfc3489bis-07.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-ietf-behave-rfc3489bis-07.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.

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 09 Jul 2007 13:50:32 -0700

I read the new draft, and I am happy with the improvements.

All nine comments in my review are fixed one way or another in this
draft.  Many thanks to do not remove the 300 error code.

Some comments:

1. Section 13: The second paragraph lists ICE, Outbound and NAT Behavior
discovery as STUN usages.  Shouldn't STUN relay be added to this list?

2. Section 13: On the list of definitions that an usage should provide,
it should be specified if a new method is idempotent (see section 7.3.1)

3. Section 16: "STUN can be used to perform this function using a
BindingRequest/BindingResponse transaction..." should be "using a
Binding request/response transaction...".

Four nits:

1. Section 10.2.2: "It is RECOMENDED that the REALM value by the domain
name.."  should be "It is RECOMMENDED that the REALM value is the domain
name..."

2. Section 7.2.2: "...must be run ontop of some kind.."  Should be "on top"

3. Section 12: "...and transaction ids were 128 bits long;" should be
"128 bits long."

4. Section 12: "...used the MAPPED-ADDRESS attribute instead" should be
"attribute instead."

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]

---

From: Philip Matthews <[email-masked]>
Date: Tue, 10 Jul 2007 16:20:02 -0400

> discovery as STUN usages.  Shouldn't STUN relay be added to this list?

First of all, we are proposing to change the name of "STUN relay"  
back to TURN.
Cullen was the person who pushed for this, but in my opinion, this  
change just
reflects reality -- everyone I know uses the terms "STUN" and "TURN",  
not "STUN"
and "STUN-relay". The latest version of the TURN spec, which should  
appear in
the archives shortly, will reflect this. I would be interested in  
hearing what
the WG feels about this change.

But to address the main question, we are proposing to view TURN as  
another
extension to STUN, not a usage. That is, you don't run TURN by itself,
but as a part of a larger usage, like ICE.

TURN by itself, also has some security problems, but with ICE a lot  
of them go away.

> it should be specified if a new method is idempotent (see section  

One of my personal goals for -07 was to try to not say the same thing
twice in two different locations. Since 7.3.1 says that any new method
must define this, perhaps this is sufficient?

- Philip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 10 Jul 2007 14:20:54 -0700

Philip Matthews wrote:
> First of all, we are proposing to change the name of "STUN relay" back
> to TURN.
> and "STUN-relay". 

I do but you are right, you do not know me.

> The latest version of the TURN spec, which should
> appear in

I think that "STUN relay" correctly describes what is in the spec, but
there could be worst names than TURN.  "router" for example.

> 
> But to address the main question, we are proposing to view TURN as another

In this case why do not merge STUN relay in the ICE spec?

> 
> TURN by itself, also has some security problems, but with ICE a lot of
> them go away.
> 
> 
> 
>>

I understand, but in this case you should make the following modifications:

Section 12: Remove "A usage must define if and when this procedure is
used", because this is already in section 13 ("Whether backwards
compatibility to RFC 3489 is required;")

Section 9: Remove "A STUN usage must describe if and when this extension
is used." because this is already in section 13 ("How a STUN client
determines the IP address and port of the STUN server;")

Section 10: Remove "... and each usage must specify if and when these
mechanisms are used." because this is already in section 13 ("What
authentication and message integrity mechanisms are used;")

---

From: Philip Matthews <[email-masked]>
Date: Tue, 10 Jul 2007 20:44:28 -0400

> In this case why do not merge STUN relay in the ICE spec?

This could be done. However:
1) The ICE spec is already pretty large, and
2) There is a chance that some usage other than ICE might use TURN
    (though I don't know what it would be right now).
Also, ICE is an MMUSIC work item, while TURN is a BEHAVE work item.

- Philip

---

From: "David Barrett" <[email-masked]>
Date: Tue, 10 Jul 2007 19:03:12 -0700

> -----Original Message-----
> From: Philip Matthews [mailto:[email-masked]]
> Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-rfc3489bis-07.txt
> 

I totally support the notion of focusing STUN/TURN on the requirements if
their actual "customers" (etc, ICE).  But are you proposing that there will
be no such thing as an official "STUN server" that exists outside of ICE?  

For example, there's no such thing as a standalone "RTP server" that exists
outside of some broader media streaming system.  Are you proposing that
similarly, there will be no standalone STUN server, but instead just clients
and servers that happen to use the STUN protocol as one of many?

I've got no strong opinion on the matter (though it actually sounds like a
nice way to clarify and constrain scope, which I'm always a fan of); I just
want to clarify the proposal.

-david

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 10 Jul 2007 19:44:44 -0700

>     (though I don't know what it would be right now).

HIP, MIP, or NUTSS, perchance, none of which will use ICE completely
as-is (HIP and MIP are very unlikely to use ICE's SDP encoding; NUTSS
might if NUTSS sticks with SIP signaling).  But all of them could 
benefit from a UDP relay.  I don't know of such a beast, defacto 
standard or not, except TURN.

> Also, ICE is an MMUSIC work item, while TURN is a BEHAVE work item.

That becomes moot when they are RFCs and their genesis in separate
working groups is lost (except perhaps the brief mention on the banner 
on the first page).

-d

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 11 Jul 2007 09:11:56 +0300

On Wednesday 11 July 2007 05:44:44 ext Dan Wing wrote:
> But all of them could

Actually, SOCKS5 (which I recall as a IETF standard track protocol) does 
support UDP relaying, including with authentication. However, it does not 
currently support SIP credentials, and TCP->UDP relaying, nor TLS->(UDP|TCP). 
Also it needs some framing for each UDP packets (i.e. no active destination).

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Wed, 11 Jul 2007 06:27:15 -0400

> want to clarify the proposal.

STUN by itself does not work very well, because there is no way for
a client to tell when it should use the reflexive address learned.
It also has some poor security properties, because there is no
way to protect or confirm the reflexive address learned.

So our idea is: STUN is now a tool. You use it in some usage, and as  
part of
that usage, you describe how you are going to fix all the problems  
with STUN.
ICE is one such usage - it fixes the problems using authenticated  
connectivity
checks. Outbound is another such usage - it avoids the problems  
because it does
not use reflexive addresses. Other usages might also be defined.

This doesn't mean that there will not be public STUN servers that  
applications
can use. It just means that a robust application should be aware of  
the limitations
of STUN and have a way to work around them.

Did this answer your question?

- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 27 Jul 2007 08:14:02 -0400

a few more comments inline:

> discovery as STUN usages.  Shouldn't STUN relay be added to this list?

Per the other notes in this thread, no.

> it should be specified if a new method is idempotent (see section 7.3.1)

I think Philip addressed this.

> Binding request/response transaction...".

fixed.

> name.."  should be "It is RECOMMENDED that the REALM value is the domain

fixed

> 2. Section 7.2.2: "...must be run ontop of some kind.."  Should be "on top"

fixed

> 3. Section 12: "...and transaction ids were 128 bits long;" should be

The semicolon is used elsewhere in this list so I think its right.

> 4. Section 12: "...used the MAPPED-ADDRESS attribute instead" should be

I believe this is correct as written.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 27 Jul 2007 05:54:49 -0700

> Marc Petit-Huguenin wrote:

[snip]

> I think Philip addressed this.

I am not sure.  Philip said that this was not added in this section
because it would be redundant with 7.3.1.  I then pointed out that other
definitions in section 13 were also redundant, but I do not know which
way the spec will be modified (or not).

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 27 Jul 2007 10:23:23 -0400

> way the spec will be modified (or not).

Section 13 is a summarization though, so even though what is in there is 
mentioned elsewhere, it needs to be in 13 once more.

-Jonathan R.