Subject: [BEHAVE] AD comments on draft-ietf-behave-nat-behavior-discovery-04

From: Magnus Westerlund <[email-masked]>
Date: Thu, 04 Sep 2008 11:47:04 +0200

Hi,

I have now performed my AD review of the NAT behavior discovery using 
STUN document. I have some comments and questions. Please answer then 
and if I am suggesting something stupid please tell me. There are 
definitly a few question that really would benefit from WG input.

1. Section 2: The expansion of STUN is wrong, please see the latest STUN 
bis draft.

2. Section 2.2: Please expand the P2P acronym.

3. Section 3.2: I am missing some motivation why this method is only 
applicable for UDP. I would recommend that one actually include that in 
the document.

4. Section 3.3: Also here I would like to know the motivation for why 
this is only applicable to UDP. Please include in document.

5. Section 4.3: "These tests should be
    performed using a port that wasn't used for mapping or other tests as
    packets sent during those tests may affect results."

The port mentioned in this sentence is the source port? Please clarify 
that in the text.

6. Section 4.5, second paragraph: I had some trouble reading this 
paragraph. It took me several tries before I got what it actually said. 
I think it would benefit from a sentence or two talking about the basic 
goal of requesting the STUN server to send a packet back over the old 
binding while using another binding to send the request. I am also 
worried that the talk about sockets are ambiguous. The important fact 
that aren't clearly expressed is the need to use different source ports 
and the same IP address (?) when sending the test request in relation to 
the first one.

7. Section 4.5: This really is a question. The third paragraph talks 
about some NATs having a behavior of only outbound keep-alives. Are 
there interest in discovering that behavior? The reason I ask is that if 
one would combine the described test with one that has potential of 
being quicker but would fail for NATs doing keep-alive on inboud traffic 
then one could learn that. In addition one could quicker learn the 
timeout. The test that are less robust is one where one creates the bind 
to measure on. Then use a second binding to request inbound traffic. 
Instead of sending a new keep-alive message before each measure on the 
binding one send the checks regularly with 5 to 15 seconds interval 
(depending on granularity desired on measurement). However, they may not 
be longer than 15 because then one could end up measure the timeout 
between measurements rather than from the intial binding creation 
request. If these measurement request stops getting in back then one 
have a timeout that is longer than the time between the binding creation 
request and the last check packet that get through. If the NAT has a 
binding that is refreshed by incoming this will not timeout while the 
text currently specified will. So by running both you learn this 
property, and in addition if the NAT doesn't do keep-alive on inbound 
traffic then you get a measurement in a single timeout period.

As I said, this is only question to learn if you have considered this 
and if it is at all a useful characterization of the NAT.

8. Section 5: "When PADDING is used, it SHOULD be 1500 bytes long, 
unless a more appropriate length is known based on the MTU of the path."
I wonder if this is missing to express the basic requirement on the 
length of the padding added? The goal of adding padding is to ensure 
that the response packet gets fragmented. The lazy way of achieving that 
on any outgoing interface is to add padding equal to one full MTU on 
that interface. The 1500 bytes are to small on interfaces that has 4k or 
larger MTUs to gurrante that this happens. I also would like to add a 
warning that if one actually have a asymmetric MTU the test here will 
not correctly work under certain usages. However the server -> client 
MTU needs to be bigger than the client-> server MTU. The only way of 
avoiding that case is to ensure that server actually adds enough padding 
to cause fragmentation already at the server first hop.

9. Section 6: Why isn't TCP and TCP/TLS discussed in this section?

10. Section 6.1, page 15, fifth paragraph: Shouldn't we recommend 
rate-limiting on requests with XOR-RESPONSE-TARGET all the time, also 
for authenticated requesters?

11. Section 6.1, page 17, first paragraph: In this paragraph, one way of 
ensuring fragmentation is to recommend that the server adds one MTU of 
padding. That could be done in all cases when the Padding attribute is 
included. However, that will prevent any cases where the client actually 
want a specific packet size. But it do guarantees fragmentation on the 
return path.

12. Section 6.1, page 17, second paragraph: "An
    ALTERNATE-SERVER attribute SHOULD NOT be included."

What does it mean if one do include one? Is that clear so that it makes 
any sense to have a SHOULD NOT, instead of MUST NOT?

13. Section 7: "CHANGE-REQUEST was
    originally defined in RFC3489 [RFC3489] but is redefined here as that
    document is obsoleted by RFC3489bis [I-D.ietf-behave-rfc3489bis]."

I can't see any difference between the RFC3489 and this version of the 
CHANGE-REQUEST attribute. So is it really redefined?

14. Section 7.3: Formal definition of the attribute value is missing. 
There is nothing defining how the bits are stuffed into the value field. 
This also applies on Sections 7.7, 7.7, and 7.8.

15. Section 7.4: The format here is defined by a normative reference to 
RFC 3489. I don't think that is appropriate. I would propose to copy the 
definition into this and only keep the informal reference.

16. Section 7.7: As the largest IP packet that can be sent is 64k, then 
you can't add up till 64k of padding data. I think the text should be 
clarified that the largest padding possible is the one that brings the 
complete packet upto 64k.

17. Section 8.1: "If the server's response
    includes a CACHE-TIMEOUT that is shorter than the client's request,
    the server is unable to satisfy the caching time requested by the
    client and the client SHOULD NOT continue to retry the request."

This is a bit confusing. I think it refers to an earlier request that 
was last sent over the binding that one has as XOR-RESPONSE-TARGET. Also 
the statement is not clear if it is the CACHE-TIMEOUT attribute or its 
value that is shorter than the request.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave