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

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

Magnus,

Thanks again for the comments.  Have tried to address these in the -05 revision.

Bruce

Magnus Westerlund wrote:
> 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.
>

fixed

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

3489bis says the server "MUST NOT ever" open a new TCP connection
outbound to the client.  It would not be terribly hard to design similar
tests for filtering, etc for TCP if that restriction was removed
(there's an additional filtering possibility of no inbound connections
at all, but that's the biggest difference), but with the current STUN
protocol, it's prohibited.

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

tried to clarify "source port" in numerous places

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

Added some clarifying text to 4.5 and 3.3 about how this is supposed to
work.  Also eliminated the term socket in favor of port since one or
multiple sockets is entirely irrelevant.

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

So the quick response is that I added a single sentence that hints you
can do this.

The longer answer is that yes I know it's possible to test for.  I think
that for any given thing we might test for, there is at least one person
who is interested in it.  However, section 4 is actually not a normative
section in this draft.  The normative text is limited entirely to the
specific attributes and how they are handled. Section 4 suggests some
ways to use the attributes and combine them in interesting ways, but it
isn't intended to restrict what you can do with these attributes.
Primarily this is because it's probably impossible to enumerate all of
the interesting things that someone might want to test.

If there's interest in trying to enumerate more tests, we can probably
add more.  I'm not quite sure how useful that would be.   I don't
believe there's a practical benefit for making them normative since
someone can just develop a "different" test that makes use of the same
attributes.

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

changed to the MTU of the interface.

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

fixed.

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

I moved this text around so that all of the rate-limiting text is in the
same place and RECOMMEND that the server rate-limit all requests unless
otherwise required by the application.

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

PADDING changed to outbound MTU

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

changed this so that MUST NOT include if any other attributes from this
draft are included.  That allows a server to load-balance somehow (if
anyone really wants to do that) but prevents confusion by including
OTHER-ADDRESS or something in a response that is really redirecting.

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

Hmmm, this is a procedural question that has been debated a few times.
My understanding of the most recent conclusion was that since 3489bis
obsoletes 3489, 3489 attributes aren't really defined anymore and we
should "redefine" them in a draft that isn't obsolete.  Happy to
change/reword as appropriate to match the correct procedure, but I've
left it that way for now.

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

There's text in 7.1 that specifies that all transport addresses are
encoded in the same manner as MAPPED-ADDRESS.  We can duplicate that
sentence in all of the sections if you like.  I've left it the way it is
for now.

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

fixed

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

tried to clarify this a bit better.

Bruce

> 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
>
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 04 Nov 2008 11:03:40 +0100

Hi,

Some further comments and questions. removing things that are resolved.

> tried to clarify "source port" in numerous places

I think it is good to clarify the issue with the port being previously
used. However, I can't really see why using a random port will solve the
issues. Also a random selected port may have been recently used. So I
think the text is overly confident that the issue is avoided with a
random port.

> someone can just develop a "different" test that makes use of the same

Okay, that is fine.

> left it that way for now.

I think the change makes this clearer and is okay.

We need to resolve the issue nr 5, before proceeding to IETF last call.

Cheers

Magnus Westerlund

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 4 Nov 2008 11:29:29 -0500

> think the text is overly confident that the issue is avoided with a

The random port was trying to address Cullen's concern that a device
configured to run tests on startup would encounter a problem
essentially every time it is rebooted where its normal application
ports aren't valid for the tests.

None of that text is actually normative.  Do you think it would be
better to have a more thorough description of why random is
recommended, and to reword it a bit to make it clear it is a
recommendation and when it is important?

Ultimately, there's no guaranteed way to ensure previous use won't
influence the result unless you actually know the binding timeout of
the NAT and hold the port for that long before using it.

Bruce

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 06 Nov 2008 16:39:23 +0100

> ports aren't valid for the tests.

Okay, a valid concern.

> recommendation and when it is important?

The problem is common unless you actually have being camping on the port
and do not allow re-use or sharing for significant long time.

> the NAT and hold the port for that long before using it.

Yes, and the text that was present gave the reader a false impression
that this wasn't the case. I propose that you draft more generic text
that talks about the problem in general and probably also the reboot
issue. I think the implementor needs to get a general warning about this
issue and watch for it. Inconsistent result may be the result of
previous users of the mapping.

Cheers

Magnus Westerlund

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 11 Nov 2008 14:55:25 -0500

draft of possible new text to describe source port selection problem
inline below.

> previous users of the mapping.

So this may be longer than desired, but I tried to write something up
that described the problem and various solutions to it depending on
the application's requirements.  Comments on this text inserted prior
to the current 4.1?

Bruce
--------------------

4.1.  Source Port Selection

   Proper source port selection is important to ensuring the usefulness
   and accuracy of the Behavior Discovery tests.  There are two
   preconditions for tests:

   o  Because mapping behavior can vary on a port-by-port basis, an
      application should perform its tests using the source port
      intended for use by the application whenever possible.  If it
      intends to use multiple source ports, it should repeat these tests
      for each source port.  Such tests should be performed sequentially
      to reduce load on the NAT.

   o  Because the results of some diagnostic checks depend on previous
      state in the NAT created by prior traffic, the tests should be
      performed using a source port that has not generated recent
      traffic.  Therefore the application should use a random source
      port or ensure that no traffic has previously occurred on the
      selected port prior to performing tests, generally by allocating a
      port and holding it unused for at least 15 minutes prior to the
      tests.

   Ensuring both of these preconditions can be challenging, particularly
   for a device or application wishing to perform Behavior Discovery
   tests at startup.  The following guidelines are suggested for
   reducing the likelihood of problems:

   o  An application intended to operate behind a NAT should not attempt
      to allocate a specific or well-known port.  Because such software
      must be designed to interoperate using whatever port is mapped to
      it by the NAT, the specific port is unnecessary.  Instead, on
      startup a random port should be selected (see below for
      recommended ranges).  An application, particularly on an embedded
      device, should not rely on the host operating system to select the
      next available port, because that might result in the application
      receiving the same port on each restart.  An application using the
     same port between restarts may not receive accurate results from
      Behavior Discovery tests that are intended to test state-related
      behavior of NATs, such as filtering and binding lifetime.

   o  An application requiring multiple ports, such as separate ports
      for control and media, should allocate those ports on startup when
      possible.  Even if there is no immediate need for media flow, if
      Behavior Discovery tests will be run on those ports, allocating
      them early will allow them to be left idle, increasing the chance
      of obtaining accurate results from Behavior Discovery tests.

   o  Although the most reliable results are obtained when performing
      tests with the specific ports that the application will use, in
      many cases an application will need to allocate and use ports
      without being able to perform complete Behavior Discovery tests on
      those ports.  In those cases, an application should randomly
      select its ports from a range likely to receive the same treatment
      by the NAT.  This document recommends ranges of 32768 to 49151,
      which is the upper end of IANA's Registered Ports range, and
      49152-65535, which is IANA's Dynamic and/or Private port range,
      for random selection.  To attempt to characterize a NAT's general
      treatment of ports in these ranges, a small number of ports within
      a range can be randomly selected and characterized.

   Those tests particularly sensistive to prior state on a NAT will be
   indicated below.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Nov 2008 15:41:49 -0600

See at the bottom

> the application's requirements.  Comments on this text inserted prior

I think the text looks fine. I do however have one question about the
source port range recommendation. Why does you include the 32768-49151
range? Isn't the dynamic range sufficient?

Cheers

Magnus Westerlund

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

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 19 Nov 2008 15:55:29 -0600

> range? Isn't the dynamic range sufficient?

I found some discussions online that seemed to indicate it would not
be unusual to configure a firewall such that inbound connections on
dynamic ports were forbidden, but connections to the upper end of the
registered ports would not be.  I don't know how common that is.  I
also don't know if that's too much information or not enough.
Firewall admins are also known to block or open specific ports in that
range, so as with everything else, no rule applies...

Bruce