headers
Philip Matthews | 1 Dec 2006 03:32
Picon

Re: STUN -> Session Traversal Underneath NAT

Perhaps even more accurate would be
"Set of Tools and Usages for NAT traversal".

- Philip

On 30-Nov-06, at 17:47 , Francois Audet wrote:

> Yes agreed.
>
> In fact, the worst names we come up with is when we try to match an
> acronym.
> For example, "Behavior Engineering for Hindrance Avoidance"...
>
>> -----Original Message-----
>> From: Philip Matthews [mailto:philip_matthews <at> magma.ca]
>> Sent: Thursday, November 30, 2006 14:37
>> To: Spencer Dawkins; Audet, Francois (SC100:3055); Pete Cordell
>> Cc: ietf-behave <at> list.sipfoundry.org
>> Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT
>>
>> I also agree with Francois and Spencer.
>> Though I will suggest that
>> "Set of Tools Useful for NAT traversal (STUN)" would be more  
>> accurate.
>>
>> And there is a history of not always having the acronym
>> correspond directly to the first letter of each work.
>> Consider, for example, RSVP (Resource Reservation Protocol).
>> I am sure folks can come up with other examples.
>>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Hisham Khartabil | 1 Dec 2006 14:36
Picon

Comments and nits on rfc3489bis-05

Apologies if there comments or nits already addressed.

General
--------
- Should TLS over TCP be TCP over TLS (there is also TLS-over-TCP)?

Section 2
----------
- ALGs have serious limitations. The security drawback is not 
mentioned. It might be worthwhile mentioning that integrity and 
confidentiality is compromised because any signed or encrypted parts of 
the application protocol message would cause failure

Section 4
---------
- Add definition for STUN Indication
- Add definition for short term credentials

Section 5
-----------
- para 3: I think more text is needed explaining the purpose of the 
Indication transaction. Text needs to talk about why Indication 
transaction is defined in this document when there are no Indications 
defined.
- para 12 and 15 (2nd last para) talk about repeats info about some 
stun usages require stun messages to be sent on the same transport 
address as the application protocol. That fine, but its kind of 
confusing since para 15 sounds like its talking about something new. 
Perhaps para 15 should say "... as mentioned above..."
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pete Cordell | 1 Dec 2006 18:59

Re: STUN -> Session Traversal Underneath NAT

I'm happy with this, although technically the acronym would be STUNT, which 
may not project the right image.

A compromise of all the suggestions so far could be:

    Set of Tools for Uncorking NATs

My only reservation with that is it makes NATs sound like fine wine which 
doesn't seem right!

On the other hand,

    Set of Tools for Unblocking NATs

makes NATs sound more like drains, which may be more appropriate!

Maybe if we want to toss around a few more ideas we can do it off-list, and 
come back when we've got a candidate.

Pete.
----- Original Message ----- 
From: "Philip Matthews" <philip_matthews <at> magma.ca>
To: "Francois Audet" <audet <at> nortel.com>
Cc: "Spencer Dawkins" <spencer <at> mcsr-labs.org>; "Pete Cordell" 
<pete.cordell <at> tech-know-ware.com>; <ietf-behave <at> list.sipfoundry.org>
Sent: Friday, December 01, 2006 2:32 AM
Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT

> Perhaps even more accurate would be
> "Set of Tools and Usages for NAT traversal".
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jonathan Rosenberg | 1 Dec 2006 23:00
Picon
Favicon

Re: STUN -> Session Traversal Underneath NAT

Ahhh. Nothing brings out opinions like a naming debate.

I think Francois got it right. I'd prefer "STUN: Set of Tools Useful for 
NAT". I like semi-derogatory things like Uncorking and Unblocking more 
for working group names (which is an IETF insider thing) and not 
protocol names (which are read by everyone).

-Jonathan R.

Pete Cordell wrote:

> I'm happy with this, although technically the acronym would be STUNT, 
> which may not project the right image.
> 
> A compromise of all the suggestions so far could be:
> 
>    Set of Tools for Uncorking NATs
> 
> My only reservation with that is it makes NATs sound like fine wine 
> which doesn't seem right!
> 
> On the other hand,
> 
>    Set of Tools for Unblocking NATs
> 
> makes NATs sound more like drains, which may be more appropriate!
> 
> Maybe if we want to toss around a few more ideas we can do it off-list, 
> and come back when we've got a candidate.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Francois Audet | 1 Dec 2006 23:09
Favicon

RE: STUN -> Session Traversal Underneath NAT

Thanks.

By the way, I got the idea by reading the Abstract which pretty much
says exactly that. 

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen <at> cisco.com] 
> Sent: Friday, December 01, 2006 14:01
> To: Pete Cordell
> Cc: Philip Matthews; Audet, Francois (SC100:3055); 
> ietf-behave <at> list.sipfoundry.org
> Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT
> 
> Ahhh. Nothing brings out opinions like a naming debate.
> 
> I think Francois got it right. I'd prefer "STUN: Set of Tools 
> Useful for NAT". I like semi-derogatory things like Uncorking 
> and Unblocking more for working group names (which is an IETF 
> insider thing) and not protocol names (which are read by everyone).
Permalink | Reply | 1 comment |
headers
Pete Cordell | 1 Dec 2006 23:42

Re: STUN -> Session Traversal Underneath NAT

Excellent.  All sorted.

Pete.
----- Original Message ----- 
From: "Francois Audet" <audet <at> nortel.com>
To: "Jonathan Rosenberg" <jdrosen <at> cisco.com>; "Pete Cordell" 
<pete.cordell <at> tech-know-ware.com>
Cc: "Philip Matthews" <philip_matthews <at> magma.ca>; 
<ietf-behave <at> list.sipfoundry.org>
Sent: Friday, December 01, 2006 10:09 PM
Subject: RE: [BEHAVE] STUN -> Session Traversal Underneath NAT

Thanks.

By the way, I got the idea by reading the Abstract which pretty much
says exactly that.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen <at> cisco.com]
> Sent: Friday, December 01, 2006 14:01
> To: Pete Cordell
> Cc: Philip Matthews; Audet, Francois (SC100:3055);
> ietf-behave <at> list.sipfoundry.org
> Subject: Re: [BEHAVE] STUN -> Session Traversal Underneath NAT
>
> Ahhh. Nothing brings out opinions like a naming debate.
>
> I think Francois got it right. I'd prefer "STUN: Set of Tools
> Useful for NAT". I like semi-derogatory things like Uncorking
> and Unblocking more for working group names (which is an IETF
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Stucker | 2 Dec 2006 02:03
Favicon

RFC3489bis-05 comments (section 8 onward)

Hi all,

Here are my remaining comments from section 8 onward:

Section 8.3.1, paragraph 5 (a.k.a. step 3):
		NIT: Change 'nulls' to 'whitespace'.

Section 8.3.1
		Last sentence in the section about pipelining... Same
question I raised about similar text in section 7.1.

Question: Is it allowable to have multiple transactions outstanding
between the same two endpoints, or is it intended that a given server
will only have one transaction outstanding from any given client? 

Suggest changing last sentence in 8.3.1 from:

"Regardless of the transport protocol, a client MAY pipeline requests
(that is, it can have multiple requests outstanding at the same time)."

...to:

"Regardless of the transport protocol, a client MAY have multiple
outstanding STUN requests (with different transaction IDs) and not wait
for completion of one STUN transaction before initiating another STUN
request to the same STUN server."

Page 18, next to last paragraph:

To match with section 8.3.3 should read: When using TCP or TLS over TCP,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lloyd Hilaiel | 2 Dec 2006 02:14
Picon
Favicon

draft-ietf-behave-rfc3489bis-05 nits

Greetings,

This first email has editorial nits of
draft-ietf-behave-rfc3489bis-05.txt.  Please let me know if the the
format (universal diffs) is inconvenient.

These 13 issues are minor and don't require a response.  I apologize if 
I duplicated previously discussed issues.  Please drop said duplicates
on the floor.

I'll send along my (marginally) deeper questions in the next day.

0. There are at least three different phrases used to refer to the same
   usage:
   "binding refresh usage", "binding keepalive usage" and
   "NAT keepalive usage".  One phrase should be chosen.
   (searching keepalive throughout reveals them all). 

1. A repeat of Philip's comment about "client" and "server" being
   potentially confusing.  Especially in the abstract where the terms
   haven't been defined yet, I found the use of the terms to be
   a bit misleading.

 <at>  <at>  -59,3 +59,3  <at>  <at> 
    allocated to them by a NAT and to keep NAT bindings open.  It can
-   also serve as a check for connectivity between a client and a server
+   also serve as a means to check connectivity between two endpoints
    in the presence of NAT, and for the client to detect failure of the

2. In section 1, the stun relay usage does not handle the case where the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Stucker | 2 Dec 2006 03:15
Favicon

RE: Review of rfc3489bis-05 up to section 8

 What if the TCP connection was established, but closed between the time
a STUN request was sent out, and a response came back in? Failure? Seems
like it would have to be, but what would the client be expected to do?

Regards,
Brian

> -----Original Message-----
> From: Saikat Guha [mailto:saikat <at> cs.cornell.edu] 
> Sent: Wednesday, November 29, 2006 8:26 PM
> To: Dan Wing
> Cc: Stucker, Brian (RICH1:AR00); 'Jonathan Rosenberg'; 
> rohan <at> ekabal.com; behave <at> ietf.org
> Subject: RE: [BEHAVE] Review of rfc3489bis-05 up to section 8
> 
> On Wed, 2006-11-29 at 17:07 -0800, Dan Wing wrote:
> > I expect that would interact poorly with TCP simultaneous-open.  
> > Saikat, any thoughts?
> >
> > > -----Original Message-----
> > > From: Brian Stucker [mailto:bstucker <at> nortel.com]
> > > 
> > >  One other thought on section 7.1... The current text states that 
> > > transport failures (ICMP errors) for UDP should be considered 
> > > failures.
> > > What about other transport failures? Does a TCP connection reset 
> > > constitute a failure of the STUN transaction?
> 
> If an app is trying TCP S-O and *only* TCP S-O, then RSTs can 
> be annoying, but apps should be doing both regular
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lloyd Hilaiel | 3 Dec 2006 01:19
Picon
Favicon

3 more comments on draft-ietf-behave-rfc3489bis-05

Hello all,

My remaining issues are 3 in number, and again, minor.  Most of
the notes I jotted down on a fresh read of rfc3489bis-05 ended up
being already addressed by folks previously...

Overall, I'm excited to see this go to RFC, and find it much clearer
(and simpler, despite the name change) than RFC 3489.  FWIW, I think
moving nat type detection out into a seperate usage was a wonderful
decision.

1. rename "magic cookie"?

   afaict, there are three roles the magic cookie serves:
   * provides a tool for demux
   * serves as a STUN version number
   * is the xor value used in encoding of XOR-MAPPED-ADDRESS
     (along with the transaction id)

   I would find it clearer if there were fewer interdependencies here,
   that is, if XOR-MAPPED-ADDRESS was encoded using a constant.  And
   the magic cookie because simply a version number.

   So I'd propose:
   1. change "magic cookie" to "STUN version number"
   2. define a 16 byte constant in the document for encoding of
      XOR-MAPPED-ADDRESS (as is done in 11.5, FINGERPRINT)
   3. everywhere we talk about the magic cookie being used as a demux
      tool, update language to refer to stun version number.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane