Skip to main content

STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
draft-ietf-midcom-stun-04

Revision differences

Document history

Date Rev. By Action
2003-03-18
04 (System) Ballot writeup text was added
2003-03-18
04 (System) Last call text was added
2003-03-18
04 (System) Ballot approval text was added
2003-03-18
04 Scott Bradner 2003-03-18 - published as RFC 3489
2003-03-18
04 Scott Bradner State Changes to RFC Published from RFC Ed Queue by Bradner, Scott
2002-12-27
04 Jacqueline Hargest State Changes to RFC Ed Queue from Approved-announcement sent by Hargest, Jacqueline
2002-12-26
04 Jacqueline Hargest State Changes to Approved-announcement sent from Approved-announcement to be sent by Hargest, Jacqueline
2002-12-26
04 Jacqueline Hargest State Changes to Approved-announcement to be sent from IESG Evaluation by Hargest, Jacqueline
2002-12-26
04 Scott Bradner 2002-12-26 - randy cleared his discuss - this should
now have passed
2002-12-26
04 (System) IESG has approved the document
2002-12-22
04 Scott Bradner 2002-12-22 - paf ok with this version
randy now only discuss
2002-12-21
04 Scott Bradner 2002-12-20 - new version to address paf's concerns
2002-12-21
04 Scott Bradner State Changes to IESG Evaluation from IESG Evaluation  :: Revised ID Needed by Bradner, Scott
2002-12-20
04 (System) New version available: draft-ietf-midcom-stun-05.txt
2002-12-17
04 Scott Bradner
2002-12-16  - note to iesg

this is the response from ekr about stun - randy requested that I ask him

Randy has an outstanding discuss …
2002-12-16  - note to iesg

this is the response from ekr about stun - randy requested that I ask him

Randy has an outstanding discuss on this issue

now what?

Scott

(response included)
2002-12-17
04 Scott Bradner
2002-12-17 - response from ekr
As far as I can tell, Steve's countermeasure is designed to ameliorate a
different attack. In this attack, the attacking …
2002-12-17 - response from ekr
As far as I can tell, Steve's countermeasure is designed to ameliorate a
different attack. In this attack, the attacking machine poses as a STUN
client and requests STUN service from the STUN server, using the
victim's address as the RESPONSE-ADDRESS. The STUN server then sends a
STUN response to that address. This allows the client to send packets to
the victim while hiding his own address.  Steve's countermeasure enables
the recipient of such a bogus STUBN packet to cooperate with the STUN
server in identifying the attacker.

This should not alleviate the attack I was concerned with. As far
as I know, there is still no fix for that.
2002-12-15
04 Scott Bradner
2002-12-14 - response form paf

My Discuss was around the extensibility which do exist in two places,
extensions and flags. IF you have this mechanism, …
2002-12-14 - response form paf

My Discuss was around the extensibility which do exist in two places,
extensions and flags. IF you have this mechanism, the flags and
extensions should be registered by IANA. But, if you don't want to have
extensions (like you here say) then the protocol should be revised and
reflect that.
2002-12-15
04 Scott Bradner
2002-12-14 - note from wg chair to paf

I recognize there are some issues around extensibility and
registration in the document and that there are …
2002-12-14 - note from wg chair to paf

I recognize there are some issues around extensibility and
registration in the document and that there are some
internal inconsistencies.  I'd like to get them straightened
out. 

STUN was done with agreement among the working group
members, the document authors, and the area directors that
it is a flawed protocol and is intended to be a temporary,
short-term solution to one particular NAT problem, and that
it would be superceded by a midcom protocol.  By allowing
for extensibility we'd be saying that it's *not* a
short-lived protocol and that we're open to the possibility
of adding functionality to it in the future.  I don't think
that's the right thing to do.  How would you prefer to see
this sorted out?

Thanks,

Melinda
2002-12-14
04 Scott Bradner
2002-12-14 - sob sent note to ekr

Eric,
        there is a new version of the stun ID (draft-ietf-midcom-stun-04.txt)
you …
2002-12-14 - sob sent note to ekr

Eric,
        there is a new version of the stun ID (draft-ietf-midcom-stun-04.txt)
you had expressed a number of concerns about the older version
one of which Randy expressed as:

  this enables an attack in which a zombied stun client is used to
  attack innocent third parties. this attack is described in the
  security considerations section. as far as ekr knows, there's no fix.

        From my understanding this version attempts to reduce the
threat of this attack (based on an idea that smb suggested) - can you take
a look to see if your worry is lessoned
2002-12-14
04 Scott Bradner
2002-12-14 - review from paf

I can not remove my discuss yet. See below.

> (2) Why not send an error message? Is there not …
2002-12-14 - review from paf

I can not remove my discuss yet. See below.

> (2) Why not send an error message? Is there not a risk that a client
> tries again, and again, and again...
>
> 8.2 Shared Secret Requests
>
> [...snip...]
>
>    If the server receives a Shared Secret Request, it MUST verify that
>    the request arrived on a TLS connection. If not, it discards the
>    request.
>
> [...snip...]
>
> 9.1 Discovery
>
> [...snip...]
>
>    For STUN requests, failure occurs if there is a transport failure of
>    some sort (generally, due to fatal ICMP errors in UDP or connection
>    failures in TCP). Failure also occurs if the the request does not
>    solicit a response after 30 seconds. If a failure occurs, the client
>    SHOULD create a new request, which is identical to the previous, but
>    has a different transaction ID. That request is sent to the next
>    element in the list as specified by RFC 2782.

I still don't understand why not an error code is sent back in 8.2.

> (5) The end of this paragraph is weird.
>
> 11.2 Message Attributes
>
> [...snip...]
>
>    Future extensions MAY define new attributes. If a STUN client or
>    server receives a message with an unknown attribute with a type
> lower
>    than or equal to 0x7fff, the message MUST be discarded. If the type
>    is greater than 0x7fff, the attribute MUST be ignored. The ordering
>    of attributes within a message is not important (except that the
>    MESSAGE-INTEGRITY attribute MUST be the last attribute), and a
> client

The new paragraph is more weird now. I don't know what this means to an
implementation:

>    Extensions, documented in standards track IETF RFCs, MAY define new
>    attributes. Attributes with values greater than 0x7fff are optional,
>    and those less than or equal to 0x7fff are mandatory to understand.

"mandatory to understand"? Especially for codes which will be
registered later.

> (8) Similar problems in other places. (a) How are extensions
> registered? (b) Should not some bits be reserved for "future expansion
> when we run out of bits"? Should not extensions be registered with
> IANA? Using the IETF process? Vendor specific extensions?
>
> 11.2.4 FLAGS
>
>    The FLAGS attribute is a series of boolean flags. It is 32 bits
> long:
>
>
>    0                  1                  2                  3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                        |A|B|C|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>    Only three flags, A,B,C, are currently defined. The other bits MAY
> be
>    used by extensions to define additional flags. Unknown flags are
>    ignored.
>
> [...snip...]
>
> 13 IANA Considerations
>
>    There are no IANA considerations associated with this specification.

I still think we have a registration issue here. Both regarding flags
and extensions. Especially together with "mandatory to understand".
2002-12-14
04 Scott Bradner State Changes to IESG Evaluation  :: Revised ID Needed from IESG Evaluation by Bradner, Scott
2002-12-14
04 Scott Bradner 2002-12-12 - iesg discussion, smb & thomas cleared discusses, randy requests input from ekr, paf not on call will review asap
2002-12-14
04 Scott Bradner 2002-12-12 - on iesg agenda
2002-12-14
04 Scott Bradner 2002-12-11 - note from WG chair - new versiuon- ready for
IESG
2002-12-14
04 Scott Bradner State Changes to IESG Evaluation from IESG Evaluation  :: Revised ID Needed by Bradner, Scott
2002-12-11
04 (System) New version available: draft-ietf-midcom-stun-04.txt
2002-11-14
03 Scott Bradner
2002-11-14 - iesg note from erik
> 9.1: For once, I *don't* want v6 compatibility -- take AAAA out....

Some folks have been talking about …
2002-11-14 - iesg note from erik
> 9.1: For once, I *don't* want v6 compatibility -- take AAAA out....

Some folks have been talking about using STUN for e.g. SIP between IPv6-only
and IPv4-only land. I don't think any details have been worked out on this
but I can see STUN potentially being useful during transition (the same
way that NAT is useful during transition).

There is a larger transition issue whether it makes sense to do specific
things like NAT-PT at the v4/v6 boundary or STUN across the boundary, or
whether it makes more sense to say that IPv6 nodes will at a minimum
get private IPv4 addresses and the existing things that deal with the
IPv4 working over NAT boxes can be applied. That would simplify the transition
issues - the things that don't work over a v4 NAT don't work over a NAT-PT
either.

But I suspect it is premature to conclude that this is the
approach the IETF should take and have them remove IPv6 support from STUN.

  Erik
2002-11-13
03 Scott Bradner
2002-11-13 - smb comments
6:      Stress that STUN servers SHOULD be located "near" the services
to be accessed, rather than being statically configured.  …
2002-11-13 - smb comments
6:      Stress that STUN servers SHOULD be located "near" the services
to be accessed, rather than being statically configured.  That can
avoid the ambiguity of "which NATs am I behind?", as it doesn't matter
-- you just want "the" global address visible to the actual service
desired.

7: RESPONSE-ADDRESS can be used to implement a reflector attack.  At a
minimum, some new attribute should be defined that gives the source
address and port of the requester.  (While UDP source addresses are
normally unreliable, the requirement for a prior TCP exchange will
help, if the source address used is the TCP source address.)  That
doesn't prevent the attack, but it makes it easier to track down.
In this case, the USERNAME and MESSAGE-INTEGRITY fields MUST be present.

8.2: I'd say that client certificates MUST NOT be used, since they're
gratuitous load on the server.

The following algorithm might be useful for stateless server operation.
Let USERNAME=, where hmac is
computed using a server-private key.  Prefix is some string;
rounded-time is the current time truncated to some boundary value,
i.e., a 10-minute multiple.  clientIP is the client's source IP
address.  The password, then, is hmac(USERNAME,anotherprivatekey). 
When a USERNAME is presented, the validity can be assessed via the
hmac.  Freshness can be ascertained via the timestamp.  And the
password can be calculated, rather than stored.

9.1: For once, I *don't* want v6 compatibility -- take AAAA out....

What is the purpose of the "discard" flag?
2002-11-13
03 Scott Bradner State Changes to IESG Evaluation  :: Revised ID Needed from Defer by Bradner, Scott
2002-11-04
03 Scott Bradner
2002-11-04 - paf discuss comments


Patrik:
(1) I don't understand how this combination of RECOMMENDED and MUST is
to work together.

8.1 Binding Requests

[...snip...] …
2002-11-04 - paf discuss comments


Patrik:
(1) I don't understand how this combination of RECOMMENDED and MUST is
to work together.

8.1 Binding Requests

[...snip...]

        It is RECOMMENDED that the server check the Binding Request for a
        MESSAGE-INTEGRITY attribute. If not present, and the server requires
        integrity checks on the request, it MUST generate a Binding Error
        Response with an ERROR-CODE attribute with class 400 and number 1.

(2) Why not send an error message? Is there not a risk that a client
tries again, and again, and again...

8.2 Shared Secret Requests

[...snip...]

        If the server receives a Shared Secret Request, it MUST verify
  that the request arrived on a TLS connection. If not, it discards
  the request.

[...snip...]

9.1 Discovery

[...snip...]

        For STUN requests, failure occurs if there is a transport
  failure of some sort (generally, due to fatal ICMP errors in
        UDP or connection failures in TCP). Failure also occurs if the
  the request does not solicit a response after 30 seconds. If a
  failure occurs, the client SHOULD create a new request, which
  is identical to the previous, but has a different transaction
  ID. That request is sent to the next element in the list as
  specified by RFC 2782.

(3) Why not follow the FTP/SMTP idea of "families" or return codes,
where the first digit tell whether one has a temporary or complete
error, success, "need more data" etc? This below is incredibly
complicated, especially given the number of words, and imply
interoperability problems. Yes, classes are defined in 11.2.9
ERROR-CODE, but I would prefer if the classes indicated "what to do
next" and not "where the error occurred". Further, section 11.2.9 which
is to be the authoritative source on what to do when error messages are
passed (I guess) doesn't say anything about when a new request is to be
sent.

9.4 Processing Binding Responses

        The response can either be a Binding Response or Binding Error
        Response.

        If the response is a Binding Error Response, the client checks
  the class and number from the ERROR-CODE attribute of the
  response. For 400 class responses with error number 2, the client
  SHOULD obtain a new shared secret, and retry the Binding Request
  with a new transaction. For 400 class responses with error
  numbers 1 and 4, if the client had omitted the USERNAME or
  MESSAGE-INTEGRITY attribute as indicated by the error, it SHOULD
  try again with those attributes. For 400 class responses with
  error number 3, the client SHOULD alert the user, and MAY try the
  request again after obtaining a new username and password. For
  400 class responses with unknown numbers, the client should alert
  the user that there was an error, and display the reason phrase
  of the ERROR-CODE response. For 500 class responses with unknown
  numbers, the client SHOULD retry the Binding Request. For 600
  class responses with unknown numbers, the client SHOULD NOT retry
  the request, and should inform the user of the failure using the
  reason phrase.

(4) Figure 2 is useful. Why not start the document with it to describe
the algorithm, and go from there? This is now part of the "examples"
part of the document, and not the protocol specification, which is very
unfortunate.

(5) The end of this paragraph is weird.

11.2 Message Attributes

[...snip...]

        Future extensions MAY define new attributes. If a STUN client
  or server receives a message with an unknown attribute with a
  type lower than or equal to 0x7fff, the message MUST be
  discarded. If the type is greater than 0x7fff, the attribute
  MUST be ignored. The ordering of attributes within a message
  is not important (except that the MESSAGE-INTEGRITY attribute
  MUST be the last attribute), and a client


(6) Also is section 11.2, why so many discarded messages? This will
force clients and servers to retry over and over again. Further, saying
types above 0x7ffff is to be discarded is weird. Is the idea that those
are _reserved_? (Which for me is a completely different thing, today it
smells like values above 0x7ffff is forbidden)

        The following types are defined:

        0x0001: MAPPED-ADDRESS
        0x0002: RESPONSE-ADDRESS
        0x0003: FLAGS
        0x0004: SOURCE-ADDRESS
        0x0005: CHANGED-ADDRESS
        0x0006: USERNAME
        0x0007: PASSWORD
        0x0008: MESSAGE-INTEGRITY
        0x0009: ERROR-CODE

        Future extensions MAY define new attributes. If a STUN client
  or server receives a message with an unknown attribute with a
        type lower than or equal to 0x7fff, the message MUST be
        discarded. If the type is greater than 0x7fff, the attribute
  MUST be ignored.

(7) How is this to work over TLS? Is the server to open a new TLS
connection?

11.2.3 CHANGED-ADDRESS

        The CHANGED-ADDRESS attribute indicates the IP address and port
  of a STUN server where responses will be sent from if the "change
  IP" and "change port" flags were set in the Binding Request.

(8) Similar problems in other places. (a) How are extensions
registered? (b) Should not some bits be reserved for "future expansion
when we run out of bits"? Should not extensions be registered with
IANA? Using the IETF process? Vendor specific extensions?

11.2.4 FLAGS

        The FLAGS attribute is a series of boolean flags. It is 32 bits
  long:


          0 1 2 3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | |A|B|C|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



        Only three flags, A,B,C, are currently defined. The other bits
  MAY be used by extensions to define additional flags. Unknown
  flags are ignored.

[...snip...]
2002-11-04
03 Scott Bradner by Bradner, Scott
2002-11-04
03 Scott Bradner
2002-11-04 - paf comments on stun
If two devices are behind the _same_ NAT box, then STUN will not help.
The devices will try to …
2002-11-04 - paf comments on stun
If two devices are behind the _same_ NAT box, then STUN will not help.
The devices will try to contact each other by sending data from the
inside of the NAT to the outside address of the NAT box.

This doesn't work for example when using NAT boxes where the NAT is
bound to an interface, and the traffic is coming in to the NAT address
from the wrong interface. The traffic will not be NAT:ed, and the box
will believe the traffic is for the box itself, and possibly/probably
respond with some ICMP.

For example pf implementations on BSD ends up being confused like this.
2002-11-04
03 Scott Bradner by Bradner, Scott
2002-11-02
03 Scott Bradner
2002-11-02 - note from chair

I'd like to think that the right answer to the TLV question
is "nobody" - that the protocol won't be …
2002-11-02 - note from chair

I'd like to think that the right answer to the TLV question
is "nobody" - that the protocol won't be 'enhanced' in the
future.

response back to chair
please provide text for a IANA considerations section that
says that
2002-11-02
03 Scott Bradner by Bradner, Scott
2002-11-02
03 Scott Bradner
2002-11-02 - note to chairs

the iesg talked about stun on thusday but some IESG members wanted
more time to review it

one issue that …
2002-11-02 - note to chairs

the iesg talked about stun on thusday but some IESG members wanted
more time to review it

one issue that did come up from teh IANA - who defines new TLVs
(maybe that should be in teh IANA considerations)
2002-11-02
03 Scott Bradner by Bradner, Scott
2002-11-02
03 Scott Bradner State Changes to Defer  :: 0 from IESG Evaluation by Bradner, Scott
2002-10-26
03 Scott Bradner 2002-10-26 - on 2002-10-31 IESG agenda
2002-10-26
03 Scott Bradner by sob
2002-10-21
03 Jacqueline Hargest State Changes to IESG Evaluation  -- 0 from Final AD Go-Ahead by jhargest
2002-10-20
03 Scott Bradner 2002-10-20 - writeup sent - put on IESG agenda
2002-10-20
03 Scott Bradner by sob
2002-10-20
03 Scott Bradner State Changes to Final AD Go-Ahead  -- 0 from Publication Requested by sob
2002-10-16
03 Scott Bradner 2002-10-16  - new version - request to publish as PS
2002-10-16
03 Scott Bradner by sob
2002-10-16
03 Scott Bradner State Changes to Publication Requested  -- 0 from AD Evaluation  -- New ID Needed by sob
2002-10-14
03 (System) New version available: draft-ietf-midcom-stun-03.txt
2002-10-13
02 Scott Bradner 2002-10-13 - update from WG chair - waiting for revised ID
2002-10-13
02 Scott Bradner by sob
2002-10-13
02 Scott Bradner State Changes to AD Evaluation  -- New ID Needed from IESG Evaluation  -- New ID Needed by sob
2002-10-05
02 Scott Bradner fix status
2002-10-05
02 Scott Bradner by sob
2002-10-05
02 Scott Bradner State Changes to IESG Evaluation  -- New ID Needed from WG/Author  -- New ID Needed by sob
2002-09-30
02 Scott Bradner
2002-09-25 - note to WG chair
From: Eric Rescorla

Scott,

As I mentioned previously, I've looked over the STUN document
and I don't know of …
2002-09-25 - note to WG chair
From: Eric Rescorla

Scott,

As I mentioned previously, I've looked over the STUN document
and I don't know of any attacks that aren't already in the document.

In my view, the major outstanding attack is the DDOS attack.
Whether this is serious enough to hold the document for,
is a policy question for the IESG. A complete writeup is
attached.

As far as the document goes, I think it isn't as clear as it could be.
I suggest adding a section like the following.

12.4 Residual Threats
None of the countermeasures listed prevent the attacks described in
Section 12.2.2.3 if the attacker is in the appropriate network
paths. Specifically, consider the case in which the attacker wishes to
convince client C that it has address V. The attacker needs to have a
network element on the path between A and the server (in order
to modify the request) and on the path between V and the server
so that it can forward the response to C. In such a situation,
the attacker can either gain access to all the application-layer
traffic or mount the DDOS attack described in Section 12.1.1.
Note that any host which exists in the correct topological
relationship can be DDOSed. It need not be using STUN.
-Ekr

From: Eric Rescorla
I was going to do bullet points, but this is easier.  STUN has a bunch
of complicated security considerations sections but there's really one
serious security problem and then a bunch of less serious ones.

The serious one is that an attacker who is able to a STUN server or a
network element close to a STUN server can mount a DoS attack on a
bunch of machines. The way this works is that the attacker
translates the client's address in the STUN request to match
the IP address of the target machine. Then, the client thinks
that it's own address is that of the target. It tells the
peer that that's it's address and then the peer sends the media
stream to the target.

E.g.
Alice wants to have Bob send her some RTP stream. She's
behind a nat so she uses STUN to figure out her IP address
to tell Bob. The attacker convinces her that her address is V
which actually belongs to Victor. Alice tells Bob "Hey send me
your RTP stream to V". If the attacker can convince enough
Alice's to do this he's mounted a DoS on Victor.

How serious is this? Dunno. The problem is that it's not just "one   
protocol". It's a single protocol that's allowing a flooding attack on
other machines that aren't even running that protocol. This concerns
me. I agree, though, that it's nowhere near as bad as Shipworm.



There are also some (minor?) issues with the TLS description:
(1) I'd like to see some clarification of the authentication
procedure. In particular, how are you supposed to check the
DNS name? It should be against the name that was originally   
looked up. I *THINK* this says that but I'm not sure.

(2) The document says:
  If a cite certificate is not used, it is RECOMMENDED that the
  user be queried to verify that the server is authorized to provide
  STUN responses.

What the heck does this mean?

-Ekr
2002-09-30
02 Scott Bradner responsible has been changed to undefined from IETF Secretary
2002-09-30
02 Scott Bradner State Changes to WG/Author  -- New ID Needed from Wait for Writeup by sob
2002-09-19
02 Stephen Coya State Changes to Wait for Writeup from Last Call Issued by scoya
2002-08-30
02 Jacqueline Hargest Due date has been changed to 2002-09-13 from
by jhargest
2002-08-30
02 Jacqueline Hargest State Changes to Last Call Issued from Last Call Requested by jhargest
2002-08-30
02 Scott Bradner 2002-08-30 - last call requested
2002-08-30
02 Scott Bradner responsible has been changed to IETF Secretary from Area Directors
2002-08-30
02 Scott Bradner State Changes to Last Call Requested from Pre AD Evaluation by sob
2002-08-30
02 Scott Bradner 2002-08-30 - publish request from WG chair
2002-08-30
02 Scott Bradner responsible has been changed to Area Directors from Working Group
2002-08-30
02 Scott Bradner Intended Status has been changed to Proposed Standard from None
2002-08-30
02 Scott Bradner State Changes to Pre AD Evaluation from In WG by sob
2002-08-30
02 (System) Last call sent
2002-08-27
02 (System) New version available: draft-ietf-midcom-stun-02.txt
2002-07-05
01 (System) New version available: draft-ietf-midcom-stun-01.txt
2002-04-29
00 Scott Bradner 2002-04-29 - from Melinda Shore
Just failed WG last call. Estimate completing WG last call
by end of May 2002.
2002-04-27
00 Scott Bradner Draft Added by Scott Bradner
2002-04-05
00 (System) New version available: draft-ietf-midcom-stun-00.txt