Subject: Re: [BEHAVE] 2nd WGLC draft-ietf-behave-nat-behavior-discovery-04

From: "Bruce Lowekamp" <[email-masked]>
Date: Mon, 3 Nov 2008 16:45:07 -0500

Thanks again for the comments.  Changes have been made in the -05 revision.

Bruce

Bruce Lowekamp wrote:
> Cullen Jennings wrote:
>> Few comments
>>
>> Test 1: The first test defined in section 4.1 You have to have a good
>> way to distinguish not UDP connectivity from the case where the STUN
>> server is down or someone put in the wrong address.
>>
>
> That text should probably be clarified to remind the reader that the
> test applies only to connectivity to the particular STUN server.  (and
> that either the client or server could be misconfigured)  In general,
> though, that qualifier is at the beginning of the document and applies
> to everything in it.
>

added a clarification there

>
>> Test 2: In test 4.2, I think it is important to identity that this test
>> has to be done for every single port the application wants to use
>> because we know that the results for different ports are often not the same
>>
>
> Will add a note that in some situations behavior may vary port-by-port.
>   Actually, this should probably also be highlighted earlier in the
> document.
>

added some text to the applicability section.  Also added something to
the beginning of Section 4 that all tests should be done with the port
the application will use.

Also, added additional clarification that Section 4 is non-normative.
Sections 5 and later are normative as they describe the processing
required for the new attributes, but the ways of combining them are just
recommended, not normative.

>
>> Test 3: This would be better if it mandated using a random source port
>> and highlight that if any device had recently done test 2 on the same
>> port, this test will fail to get the correct result and it fails in a
>> way that suggests things will work that don't. It may sound odd to think
>> one might get the same port but often when an embedded system reboots,
>> it might run the same tests again at the same IP address and with ports
>> like this.
>>
>
> that's a good idea.  Will clarify that in 3.2 and 4.3.  Will also add
> some text to point out the interaction between this and the previous issue.
>

Added quite a bit of text about this.

>> Section 4.4 - given the rate limiting of NATs, I would give some advice
>> that was more implementable than "care must be given". I'd specifically
>> rate limit to something like no more than X stun packets per second. It
>> would be nice to discuss here how long these tests can take even when
>> they are done in parallel.
>>
>
> Do you have a suggestion for the value of X?  I don't think 4787
> explicitly addresses this.
>

Added a requirement in Section 5 that requests not be sent out more
often than 10 per second and that they be paced so that the
retransmissions don't synchronize.  Referenced that in 4.4.

>
>> Section 4.5 - the XOR-RESPONSE-TARGET just sort comes out of nowhere and
>> is a bit hard to understand when reading the draft from front to back
>>
>
> It was used earlier in 3.3, but I agree it's not well defined there,
> either.  Will try to make the introduction clearer.
>

added some more text in both places

>> The whole XOR-RESPONSE-TARGET has all the same security problems and
>> issues as TURN. Instead of reinventing it all here, why not just use
>> TURN to be able to send the packets to where you want them?
>>
>
> I disagree that the same security issues are present (or at least in the
> same magnitude).  In particular, XOR-RESPONSE-TARGET is even more
> limited in applicability in order to prevent it from being used for any
> significant type of attack.  In addition to the precautions already in
> the current text, a previous revision required authentication for all
> uses of XOR-RESPONSE-TARGET, but many people objected to this being too
> strong compared to the potential threat this method offered, and instead
> group consensus (almost unanimous as I recall) was for allowing the
> current CACHE-TIMEOUT state/rate-limiting approach while allowing those
> who desire to still require authentication.  While you're right that
> there is still a risk of a state attack on the server, the state
> required to store is very small, is stored only on transactions that
> request it, and the CACHE-TIMEOUT attribute provides feedback to the
> client whether the request can complete.  Furthermore, the consequences
> of being unable to server new requests due to a DoS attack on the server
> are not nearly as dire for behavior discovery as for TURN.
>
> Regarding TURN as a solution, that seems incredibly heavyweight for this
> application, although I don't see a reason not to say that this test
> could be implemented that way.  You'd have to be careful, however, to
> make sure that neither end of the TURN connection is running any
> keepalives, which might be difficult since TURN specifies both STUN
> keepalives and TURN keepalives for its connections.
>
>> In section 6.1 where you have "the server must verity that it has
>> previously..." I think this must needs to be a MUST
>>
>
> yes

fixed

>
>> I will note the RESPONSE-TARGET design forces the server to remember for
>> some time some state about every binding request.
>>
>
>  From Section 5:
>
>   If a client intends to utilize an XOR-RESPONSE-TARGET attribute in
>     future transactions, as described in Section 4.5, then it MUST
>     include a CACHE-TIMEOUT attribute in the Request with the value set
>     greater than the longest time duration it intends to test.
>
> so it only needs to store state for binding requests that included the
> CACHE-TIMEOUT attribute.
>
>> Section 5.1 - the SRV service name needs to be in the IANA registry
>>
>
> true
>

fixed

>> Cullen <as an individual contributor>
>>
>>
>>
>> On Aug 7, 2008, at 18:26 , Dan Wing wrote:
>>
>>> I'd like to do a quick one week 2nd WGLC on "NAT Behavior Discovery Using
>>> STUN",
>>> <http://tools.ietf.org/html/draft-ietf-behave-nat-behavior-discovery-04>.
>>> This will end on August 14th.
>>>
>>> Please send comments to the authors (CC'd) and the list.
>>>
>>> -d
>>>
>>> _______________________________________________
>>> Behave mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/behave
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave