Re: [BEHAVE] FW: Last Call: draft-ietf-behave-nat-behavior-discovery (NATBehavior Discovery Using STUN) to Experimental RFC

[Bruce Lowekamp <[e-mail]>]

Christian,

Thanks for the comments.  Responses inline.

On Wed, Apr 1, 2009 at 3:19 AM, Christian Huitema
<[e-mail]> wrote:
> I tend to agree with Cullen on some points. Instead of a draft presenting a set of algorithm, I would rather see a draft presenting a set of tools that can be useful for characterizing local connectivity, and presenting these tools as justifying a new set of STUN options that applications developers could then use as they see fit.
>

So most people miss this, which may mean it needs to be clarified more
somehow, but the algorithm section is actually not normative.  The
STUN attributes and their processing is normative, but the intention
has always been that the algorithms be an example of what you can do
with them, but not necessarily the only thing you can do with them,
although probably a good starting point. (In fact, a few people have
suggested more complex tests using the existing attributes, but I've
hesitated to put anything like that in there.)

Within that structure, does that essentially meet what you're thinking
of?  Certainly some verbiage can be added to emphasize this point
more---since it's a common question, maybe it should be added.  It
would be possible to reverse the order, I suppose, and do things in
the other direction, although then for people who didn't follow the
whole 3489 evolution, I think it might be a really hard read to define
a bunch of stuff without explaining how it should be used.


> The draft proposes a set of algorithms to characterize a NAT. As Cullen points out, any of these algorithms has weaknesses. The main weakness is that the behavior of NAT is often transient, e.g. different port mapping algorithms depending on whether or not the internal tables are near saturation, or not. So, any attempt to present an algorithm as a definitive classifier is, by nature, weak. On the other hand, even weak attempts are useful, especially in peer-to-peer applications, but also for network management and debugging. There is a tradeoff between resource consumed and precision of the characterization. This tradeoff is largely for the application developers and users to decide.
>

I think we are in agreement here.  The real test will be how
application protocols are designed to make use of these techniques.  I
have some ideas for how they would be designed in P2PSIP, but haven't
written anything up yet, trying to focus on just getting the basic
mechanism in.

What I would like to see happen is sort of like the UNSAF IAB
considerations.  If you're going to use these STUN attributes, you
must answer these questions.  I don't know if that's really necessary
since this draft is experimental---there will be enough of a "wait,
how are you using this experimental protocol?" that I think future
drafts will get scrutiny, and in fact that has already flagged a
couple of drafts as questionable already.

> The interesting question is, what mechanisms do application developers need, in addition to the basic response system defined in STUN? Most of these new mechanisms fall direct a server to send packets to a different address, to a different port, or at a different time, plus indeed a negotiation mechanism to determine whether such mechanisms are available. I don't see much harm in defining these mechanisms and the corresponding options. Indeed, I see some goodness in defining them once, in the IETF.
>
> The main goodness comes form a way to control the use of the mechanisms. Sending responses to a different address, to a different port, or at a different time has a risk. Such mechanisms can be used for denial of service attacks. If we are convinced that the draft mitigates such denial of service attacks, then we should register the corresponding attributes.
>

I believe the authentication and CACHE-TIMEOUT mechanisms in the draft
are sufficient for preventing DoS, and there was consensus for that
the last time the change was made and presented a few meetings ago,
but welcome any further comments on the issue.

Bruce



>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Dan Wing
>> Sent: Tuesday, March 31, 2009 8:09 PM
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: [BEHAVE] FW: Last Call: draft-ietf-behave-nat-behavior-
>> discovery (NATBehavior Discovery Using STUN) to Experimental RFC
>>
>> Forwarded for those that don't follow the main IETF list.
>>
>> Please reply to the list if you agree or disagree with the points raised
>> by
>> Cullen.  Thanks.
>>
>> -d
>>
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Cullen
>> Jennings
>> Sent: Tuesday, March 31, 2009 9:53 AM
>> To: IETF Discussion; IESG IESG
>> Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-nat-behavior-
>> discovery
>> (NATBehavior Discovery Using STUN) to Experimental RFC
>>
>>
>> I was somewhat shocked to see the draft in IETF Last Call. The last
>> time this draft was discussed at the microphone in Behave, many people
>> were very concerned that it id not possible to correctly characterize
>> a NAT without using more than one address behind the NAT. The tests
>> done on on NATs by the researches at MIT did that, so did the the
>> stuff from Cornell, as did draft-jennings-behave-test-results. The
>> reason why this was needed is largely the reason why the IETF invented
>> ICE. Initially folks thought that STUN alone would be enough to do NAT
>> traversal. This turned out not to be true, STUN deprecated those parts
>> and ICE was started. This draft fails to describe the types of test
>> that have actually been found to work and just reinstates the stuff
>> that was deployed and failed and then deprecated out of STUN.
>>
>> Now this draft pays some lip service to the fact that it basically
>> won't work. You can read section 1 and get the full idea. The first
>> and 2'nd par basically say this won't work. Then para 3 proposes this
>> is experiment to find out something we already know the answer to.
>> When this work was chartered, it was about making a way to
>> characterize NATs and describe them in a controlled lab like
>> environment. It was not about resurrecting exactly the part of STUN
>> that had been tried, failed , and deprecated.
>>
>> Specific problems with the draft....
>>
>> 2.2 - this just won't work. The test described in this draft will not
>> find out if the node is behind an endpoint independent nat. I have
>> specific nats where it won't work. I have explained to the authors why
>> it won't work. The answer I get back is "it might work some of the
>> time". It true it might work some of the time but we all agree there
>> are many NATs for which it will not work.
>>
>> Other section that don't work are 3.1, 3.2, 3.3, 3.4, 3.5, 3.5 - uh
>> all of them actually. I'm glad to provide details on why they don't
>> work but I have in the past and we not really debating if they work or
>> not. The authors believe there is sufficient text at the beginning of
>> the draft in section 1 that it is OK that these fail in many cases and
>> don't need to be mentioned again. We not debating these work some of
>> the but not all the time - everyone agrees on that.
>>
>> Section 4.1 - The results in here will be just wrong for ports
>> different than the one the test was run on. The response to this was
>> to add "use same port when possible". That's not going to exactly
>> cause applications to work.
>>
>> Section 4.2 - Can't really separate the topic from if UDP is blocked
>> from if the STUN server is down.
>>
>> Section 4.4 - this fails if the port was recently used for similar
>> tests from same stun server. There no way to know this as an
>> application. This type of test can work in lab condition where all
>> traffic on NAT is controlled but it operational networks it will fail.
>>
>> It is possible to do timing testing using just the change ip flag. The
>> REPSONSE-TARGET stuff is not needed and open up the possibility to
>> have a STUN server send packets to places that it should not which
>> causes IDS system to black list all traffic from the STUN server thus
>> making it unusable for other clients. The ability to tell the STUN
>> server to send packets to arbitrary locations would be fine for a
>> system in a lab used to characterize a NAT but is not a good idea for
>> internet deployed STUN servers.
>>
>> The bulk of these issues were sent Aug 28 to behave list during the
>> 2nd WGLC. I requested agenda time during IETF 74 to discuss these
>> issues but it was denied.
>>
>> In summary -The approaches described in this draft are known to fail
>> with many NATs. I don't see any evidence of the WG actually having
>> read this draft much less have consensus on the approach in it. I
>> think the WG should spend meeting time to discuss the topic and decide
>> what to do. The key topic in my mind is we are defining a document
>> that allows us to characterize a NAT in a lab or if we are trying to
>> make something that works in field and can be used to aid NAT
>> traversal in applications.
>>
>> Cullen <in my roll as individual contributor and ex chair of behave>
>>
>>
>>
>>
>>
>> On Mar 10, 2009, at 8:44 AM, The IESG wrote:
>>
>> > The IESG has received a request from the Behavior Engineering for
>> > Hindrance Avoidance WG (behave) to consider the following document:
>> >
>> > - 'NAT Behavior Discovery Using STUN '
>> >   <draft-ietf-behave-nat-behavior-discovery-06.txt> as an Experimental
>> > RFC
>> >
>> > The IESG plans to make a decision in the next few weeks, and solicits
>> > final comments on this action.  Please send substantive comments to
>> > the
>> > [e-mail] mailing lists by 2009-03-31. Exceptionally,
>> > comments may be sent to [e-mail] instead. In either case, please
>> > retain the beginning of the Subject line to allow automated sorting.
>> >
>> > The file can be obtained via
>> >
>> http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-behavior-
>> discovery-0
>> 6.txt
>> >
>> >
>> > IESG discussion can be tracked via
>> >
>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
>> 15728&
>> rfc_flag=0
>> >
>> > The following IPR Declarations may be related to this I-D:
>> >
>> > https://datatracker.ietf.org/ipr/919/
>> > https://datatracker.ietf.org/ipr/945/
>> >
>> >
>> > _______________________________________________
>> > Behave mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/behave
>>
>> _______________________________________________
>> Ietf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ietf
>>
>> _______________________________________________
>> Behave mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/behave
>
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave
>