Subject: [midcom] Last call reminder

From: [email-masked]
Date: Mon, 22 Jul 2002 08:40:40 -0400

The STUN draft is in WG last call, which closes on Wednesday
the 24th.  Speak now or forever hold your peace.

http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt

Melinda

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 22 Jul 2002 11:37:00 -0700

> http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt

Two nits are that the I-D needs to have " nat" changed to " NAT",
and " stun" to " STUN".

Section 11.1, which defines the binary values of the various
messages, should indicate which hex values are undefined
and how they their use by an implementation should be correctly
documented (via an IANA registration or via a new RFC, or
both).  I noticed several other 11.* sections also don't
define how unused fields should be defined; perhaps 11.0
can say something regarding the entire section.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 22 Jul 2002 19:03:54 -0700

Section 10.2, "Binding Lifetime Discovery", doesn't explain what
a client is supposed to do with this information.  It's somewhat
obvious that a client would use this information to decide when
to send a keepalive packet (to keep the NAT binding active), but
it would be useful to point out the reason a client would want
to learn how long a binding remains active.

What needs to be discussed -- either in 10.2 or 14.3 ("Brittleness
Introduced by STUN") is that any learning of the binding lifetime
is only valuable if the NAT device doesn't release the binding
prematurely due to a reboot, exhaustion of UDP ports for new
connections, or other actions.  Premature loss of a binding
must be detected by whatever keepalive mechanism is used by
the client (thus, a keepalive that doesn't report a broken
binding is insufficient).

-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Monday, July 22, 2002 5:41 AM
> To: [email-masked]
> Subject: [midcom] Last call reminder
> 
>

---

From: "Pete Cordell" <[email-masked]>
Date: Wed, 24 Jul 2002 09:08:34 +0100

Here's some editorial errors I found when skimming through STUN.  (I'm
afraid I didn't give it a thorough read.)

8.1 (Clarity): If the STUN Shared Secret
   Request was used, the key MUST be the {one placed}->{TARGET-OTP}
   in a Shared Secret
   Response to a Shared Secret Request that had a TARGET-TID equal to
   the transaction identifier in the Binding Request.

It would be nice to re-word this paragraph, but I've tried and it's
difficult!  Best I could do is below, but its not much of an improvement.

   If the STUN Shared Secret
   Request was used, the key MUST be the TARGET-OTP from the Shared
   Secret response corresponding to a
   to a Shared Secret Request containing a TARGET-TID equal to
   the transaction identifier of the Binding Request.

8.2 (Typo): SHOULD {prevent} -> {present} a site certificate ?

8.2 (Functional): 'The server MUST always return the same TARGET-OTP for two
   requests with the same TARGET-TID.'

   This sounds like a way that an attacker can learn the TARGET-OTP
   corresponding to a TARGET-TID.  This could be useful in an attack.
   Also, stated as is, it does not allow the server to change the key
generation
   mechanism (say a master secret) from one month to the next.

11.2.6 (Typo): TARGET-TID: Re: 'This MUST be equal to the transaction ID
that will
   be used in Binding Requests that contain the shared secret learned from
the
   exchange.'  This doesn't seem right.  Maybe it should be:

   This MUST be
   equal to the transaction ID that will be used in Binding Requests
   that {contain}->{are authenticated by} the shared secret learned from the
exchange.

(General (Clarity): Still think CHANGED-ADDRESS should be CHANGE-ADDRESS to
ties in more closely with the text 'The fourth attribute is the
CHANGE(D)-ADDRESS attribute. It is present in Binding Responses. It informs
the client of the source IP address and port that would be used if the
client requested the "change IP" and "change port" behavior.'.

It also implies that the address has been changed, but in many cases it
hasn't.  It's readily confused with MAPPED-ADDRESS for the first time
reader.  It is possible for someone to mis-interpret CHANGE-ADDRESS, but
being a verb type thing and then containing a description and appearing in a
response readers can more readily dismiss those erroneous interpretations.
But the world won't end if its not changed.)

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Jul 2002 15:11:22 -0400

Thanks for your comments. Responses inline.

> Two nits are that the I-D needs to have " nat" changed to " NAT",

Fixed. Note that I have kept the verb "natted" all lowercase however.

> both). 

It is my hope that new messages won't be needed, but I will add a 
sentence that says new ones can be defined in RFCs, and a server that 
receives a message it doesn't know about simply discards it.

  I noticed several other 11.* sections also don't
> can say something regarding the entire section.

The spec talks about unknown attributes, unknown address families, and 
flags, all of which have defined behavior. For errors, the spec 
addresses unknown numbers, but not unknown classes. I'll add a sentence 
that says unknown classes are treated as 400.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Jul 2002 15:18:31 -0400

> to learn how long a binding remains active.

I added the following text:

STUN can also be used to discover the lifetimes of the bindings
created by the NAT. In many cases, the client will need to refresh the
binding, either through a new STUN request, or an application packet,
in order for the application to continue to use the binding. By
discovering the binding lifetime, the client can determine how
frequently it needs to refresh.

> connections, or other actions. 

Since the client doesn't own the binding, how does it release it? The 
only way it can be released is through inactivity in the NAT. A reboot 
of the client won't cause that; if it sends a STUn request on startup on 
the same local port/address, it will get the same public address back as 
long as it hasn't expired in the NATs.

So, I do not see the issue here.

Thanks,
Jonathan R.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 24 Jul 2002 12:26:27 -0700

> frequently it needs to refresh.

Thanks.

> only way it can be released is through inactivity in the NAT.

You're tyinking of a reboot of the STUN client.  I'm thinking of a
reboot of the NAT itself -- the Linksys box, for example.  This 
could be a result of a reset (to load new firmware), power failure,
software fault, remote DoS, etc.

> A reboot 

It's pretty unlikely it'll send a STUN request on startup using the same
local port/address, but if you're expecting this, it's part of the
brittleness of STUN and this expectation should be mentioned in the
brittleness section.

-d

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Jul 2002 15:29:32 -0400

> software fault, remote DoS, etc.

Ah. I misunderstood. Yes, a reboot of the NAT could taint the binding 
lifetime results. I'll mention this in the section on lifetime discovery 
and in the brittleness section.

-Jonathan R.