NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)
draft-ietf-behave-nat-behavior-discovery-08

[Ballot comment]
[Note: I have moved from an open position to 'Abstain'.  On the telechat, I indicated I would
remain as an open position, but I later discovered that comments associated with open
positions are not displayed in some tracker interfaces. The change in position was designed
to ensure the comments were displayed to the authors just in case they decide to address
them.]

It seems clear that two of the conditions for NAT behavior discovery to be generally
useful are
(1) detecting the "correct" information a reasonably high percentage of the time; and
(2) unambiguous determination that the fallback mechanism should be invoked.

It was not clear from my reading that these issues are addressed.

The experiments as defined do not seem to determine (1); should this be added?

I could not find an algorithm for (2) in the document.  Is this as simple as "connection
failed, move to fallback" or is it application-dependent?  Note that the algorithm for
(2) can have false positives (i.e., scenarios that invoke the fallback unnecessarily)
as long as we don't have false negatives.

[Ballot comment]
At the end of Section 1:

  If a draft specifies the use of any portion of this STUN usage, that
  draft MUST document

Probably some other term than 'draft' should be used

[Ballot discuss]
1. The document presents as principal usage of NAT behavior discovery network diagonstics for 'network administrator or system programmer trying to determine the causes of network failure; particularly when behavior varies by load, destination, or other factors that may be related to NAT behavior'. This almost sounds like another OAM layer, or duplicating the OAM layer functionality. It is not clear however how this is going to be activated, will this run permanently or on demand, how are results being collected by an operator using discovery as a diagnostics tool

2. I do not understand well what 'experimental success' section 2.3 refers to. This is not about the success of the experiment of the discovery method, but rather about whether an application can improve its behavior. Using the 'Experimental Success' title for this section is confusing.

[Ballot discuss]
The usage of RESPONSE-TARGET seems like it would only need to allow the response port, not IP address to be changed. This would improve the security situation. Why is the IP address allowed to change?

[Ballot comment]
Note that I have not determined a ballot position yet (waiting to hear what Cullen says)
so these issues might still be moved to a discuss.

It seems clear that two of the conditions for NAT behavior discovery to be generally
useful are
(1) detecting the "correct" information a reasonably high percentage of the time; and
(2) unambiguous determination that the fallback mechanism should be invoked.

It was not clear from my reading that these issues are addressed.

The experiments as defined do not seem to determine (1); should this be added?

I could not find an algorithm for (2) in the document.  Is this as simple as "connection
failed, move to fallback" or is it application-dependent?  Note that the algorithm for
(2) can have false positives (i.e., scenarios that invoke the fallback unnecessarily)
as long as we don't have false negatives.

[Ballot comment]
There are a few constants called out in the document (15 minutes for holding an unused port, not generating more than ten new transactions per second, etc.). Providing some motivation for the values you chose would be useful.

In section 6.1, "ensure that it does not generate a Response on a particular address"
  should be
                "ensure that it does not generate a Response to a particular address"
  The sentence after that would really benefit from simplificaiton.

Nits: The end of section 2.2: "these two requirements" point back to a list of 3 things.
      2nd paragraph of 4.5: "Section Section"
      Just before 5.1: expand RTOs

[Ballot comment]
Please consider the changes raised in the Gen-ART review by
  Pete McCann.  Pete reviewed -06, but the changes needed to address
  his comment were not made in -07.  The review can be found here:

  http://www.softarmor.com/rai/temp-gen-art/draft-ietf-behave-nat-behavior-discovery-06-mccann.txt

[Ballot discuss]
This is a good document & I have a few comments.  Most of the comments are minor; the question about discovering a STUN server with this new usage supported is probably the biggest issue.  But it's probably not a blocking issue, so I plan to clear this DISCUSS and let the authors handle this input as they will, after getting a chance to discuss on the telechat.   

Section 1.

Got really confused reading this paragraph for a number of reasons: agency, context, and obsolete references.

  The applications of this STUN usage are very different than the
  original use of RFC3489 [RFC3489], which was intended for static
  determination of device behavior.  The NAT Behavior Discovery STUN
  usage makes an explicit statement that it is not, and cannot be,
  correct 100% of the time, but is still very useful.  More generally,
  one of the important differences between 3489 and ICE is that ICE
  ensures there is always a fallback to TURN, and thus avoids the
  problem experienced by 3489-based applications that tried to
  determine in advance whether they would need a relay and what their
  peer reflexive address will be, which are both impossible.  This STUN
  usage requires an application using it to have a fallback, but unlike
  ICE's focus on the problems inherent in VoIP sessions, doesn't assume
  that it will only be used to establish a connection between a single
  pair of machines, and so alternative fallback mechanisms may make
  sense.  For example, in a P2P application it may be possible to
  simply switch out of the role where such connections need to be
  established or to select an alternative indirect route if the peer
  discovers that, in practice, 10% of its connection attempts fail.


If I was able to interpret correctly, then this restatement *ought* to be correct and provide a little more context.  In addition, it reflects that STUN is now RFC5389, which probably needs to be fixed elsewhere too.  "This STUN usage" is also pretty hard to qualify when other STUN usages are also being discussed ("the STUN usage defined in this specification" is clear but long), so it would be good to give this STUN usage a name...?

  The applications of this STUN usage differ from the
  original use of STUN (originally [RFC3489], now [RFC5389]).  This specification
  acknowledges that the information gathered in this usage is not, and cannot be,
  correct 100% of the time, whereas STUN focused only on getting
  information that could be known to be correct and static. 

  This specification can also be compared to ICE.  ICE avoids the
  problem experienced by applications using STUN to
  determine in advance whether they would need a relay and what their
  peer reflexive address will be, which are both impossible [are these really individually impossible or just impossible to do together or impossible to do in advance?].  ICE avoids
  this problem by falling back to TURN, another usage of STUN. 
  ICE focuses on problems inherent in VoIP sessions, which require a connection between
  a single pair of machines.  The STUN
  usage defined in this specification requires an application using it to have a fallback, but doesn't assume
  that it will only be used to establish a connection between a single
  pair of machines, and so alternative fallback mechanisms may make
  sense.  For example, in a P2P application it may be possible to
  simply switch out of the role where such connections need to be
  established or to select an alternative indirect route if the peer
  discovers that, in practice, 10% of its connection attempts fail.


Section 2.

The acronym expansion for STUN has changed, it's Session Traversal Utilities, not Simple traversal Under.

"NAT/FW" is not defined... I assume this is "NAT/Firewall"?

Section 3.6 "3.6. Detecting Generic ALGs" --> define or expand ALG acronym




Section 5.1

The first phrase in this section implies that the client could configured with a transport address to a STUN server supporting this usage, but how would it know?  Couldn't it be configured with a transport address to a STUN server that does *not* support the usage?  Is there a way of testing support for this usage that can't be conflated with a NAT failure?


Section 7.3

"It is useful for detecting twice NAT configurations." --> Should this be "double NAT configurations"?

IANA questions/comments:


- in Action 1 you ask to assign STUN Attribute 0x0003 (CHANGE-REQUEST),
but that attribute is Reserved in the registry. Did you intend to
un-reserve the attribute? Or should we assign the next available
value?

- Where should we register the values in Action 4?


Action 1 (Section 10.1):

Upon approval of this document, IANA will make the following
changes in the "STUN Attributes" registry at
http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml

OLD:

Value Name Reference
----- ----------------- --------------------
0x0003 Reserved; was CHANGE-ADDRESS [RFC5389]

NEW:

Value Name Reference
----- ----------------- --------------------
0x0003 CHANGE-REQUEST [RFC-behave-nat-behavior-discovery-06]


Action 2 (Section 10.1):

Upon approval of this document, IANA will make the following
assignments in the "STUN Attributes" registry at
http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml

Value Name Reference
----- ----------------- --------------------
0x0027 XOR-RESPONSE-TARGET [RFC-behave-nat-behavior-discovery-06]
0x0028 XOR-REFLECTED-FROM [RFC-behave-nat-behavior-discovery-06]
0x0026 PADDING [RFC-behave-nat-behavior-discovery-06]
0x8027 CACHE-TIMEOUT [RFC-behave-nat-behavior-discovery-06]
0x802b RESPONSE-ORIGIN [RFC-behave-nat-behavior-discovery-06]
0x802c OTHER-ADDRESS [RFC-behave-nat-behavior-discovery-06]


Action 3 (Section 10.2):

Upon approval of this document, IANA will make the following
assignments in the "STUN Error Codes" registry at
http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml

Value Name Reference
----- ----------------- --------------------
481 Connection does not exist [RFC-behave-nat-behavior-discovery-06]
503 Service Unavailable [RFC-behave-nat-behavior-discovery-06]


Action 4 (Section 10.3):

We are not clear on which registry these belong in. Should these
be registered in the proposed combined service name and port numbers
registry?

_stun-behavior._udp UDP
_stun-behavior._tcp TCP
_stun-behaviors._tcp TLS over TCP


We understand the above to be the only IANA Actions for this document.

Document shepherd write-up for draft-ietf-behave-nat-behavior-discovery-04
date: 29-Aug-2008

(1.a) Who is the Document Shepherd for this document?

Dan Wing, dwing@cisco.com

Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Yes.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

No concerns.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

No concerns.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There have been concerns that the procedures described in this document
might be used to predict a NAT's behavior, which would in turn modify
application behavior. It has been found this is risky because NAT behavior
is known to change. Thus, this document is Experimental and also contains
an Applicability section. These two things have reduced the working
group's concerns.


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is solid WG consensus behind this document; many of its procedures
are based on procedures in RFC3489.



(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

There has been no extreme discontent.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough.

Yes.

Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews?

Yes.

If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

intended status: Experimental


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

All references are verified by the document shepherd, and are good.


(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

The document registers some new STUN attributes, following the procedures
of draft-ietf-behave-rfc3489bis (which is the STUN Internet Draft).


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The document contains no formal language.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.


This specification defines an experimental usage of the Simple
Traversal Underneath Network Address Translators (NAT) (STUN)
Protocol that discovers the presence and current behaviour of NATs
and firewalls between the STUN client and the STUN server.


Working Group Summary
Was there anything in the WG process that is worth noting?
For example, was there controversy about particular points
or were there decisions where the consensus was
particularly rough?

The original intent was to publish this specification as Informational,
but the working group decided Experimental would be a better track in
order to more clearly convey the risky nature of attempting to
determine a NAT's behavior.


Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification?

Two vendors are known to implement it.


Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?

They are listed in the acknowledgements section.

If
there was a MIB Doctor, Media Type, or other Expert Review,
what was its course (briefly)? In the case of a Media Type
Review, on what date was the request posted?

This document did not include such reviews.


Personnel
Who is the Document Shepherd for this document?

Dan Wing, dwing@cisco.com

Who is the
Responsible Area Director?

Magnus Westerlund, magnus.westerlund@ericsson.com

If the document requires IANA
experts(s), insert 'The IANA Expert(s) for the registries
in this document are .'

The IANA Expert(s) for the registries in this document are .