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

From: Bruce Lowekamp <[email-masked]>
Date: Tue, 02 Sep 2008 16:35:17 -0400

Sorry, meant to respond to this over the weekend.

I'm sure these won't be the only issues raised that need clarification.

Bruce

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.

> 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.

> 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.

> 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.

> 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.

> 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

> 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

> 
> 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