Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01

From: "Francois Audet" <[email-masked]>
Date: Mon, 23 May 2005 11:00:14 -0700 (PDT)

Thanks to all,

This is a formal proposal on how to move forward, with concrete text.

------------------------

How about this for REQ 7.

In the Requirements section:

REQ-7: In order to maximize application transparencyIt is RECOMMENDED that 
       a NAT have an "Endpoint independent filtering" behavior. 
       If a more stringent filtering behavior is desired, it is RECOMMENDED 
       that a NAT have an "Address dependent" behavior.

In the REQ-7 justification section would be modified as follows:

REQ-7: The recommendation to use endpoint independent filtering is aimed at
       maximizing feature transparency, in particular for applications that
       receive media simultaneously from multiple locations (e.g., gaming),
       or applications that use rendezvous techniques. However, it is also
       possible that in some circumstances, it may be preferable to have
       a more stringent filtering behavior. Filtering independently of the 
       external endpoint is not as secure: an unauthorized packet could get
       a specific port while the port was kept open if ti was lucky enough
       to find the port open. In theory, filtering based on both IP address
       and port is more secure than filtering based only on the IP address
       (because the external endpoint could in reality be two endpoints behind
       another NAT, where one of the two endpoints is an attacker): however, such
       a policy could infere with applications that use one than one port.

I'd like a Yay or Nay on the text above.

---------------------

Wordy terminology:
  As for the wordy terminology for some of the names of behaviors, I also agree
  (the reasons for wordy names are historical). I can go through the text and simplify.

------------------------

REQs in-line:
  Bryan feels strongly about copying/pasting the REQs from section 12 in-line in the
  text as they occur, to help the reader. I personally think it is a reasonable
  suggestion. Is there any STRONG objection to this? (Cullen in particular, I'd like to 
  hear from you).

-------------------------

Determinism:
  I propose that to address Bryan's concern, I put a note in section 4.1 and 5.1
  refering to the Deterministic behavior section. I also propose to change the first
  sentence of section 8 to the following:
    The classification of NATs is further complicated by the fact that under some
    conditions the same NAT often exhibits different behaviors, especially for 
    mapping and filtering.

-------------------------

Again, I'd like a Yay or Nay from people on the points above.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Peterson, Jon
> Sent: Friday, May 20, 2005 16:48
> To: Behave
> Subject: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01
> 
> 
> 
> In light of the recent Last Call discussions about
> behave-nat-udp, I wanted to make a few comments.
> 
> Regarding REQ-7, it seems pretty clear to me that there is no
> immediate consensus to endorse endpoint-dependent or 
> endpoint-independent filtering. Consequently, in the interest 
> of time I'd like to make the modest proposal that REQ-7 
> endorse neither, but instead state that both these modes (and 
> address-specific filtering) should be supported. Is there 
> some advantage to privileging one over the other?
> 
> I see no great need to specify the maximum datagram length
> that NATs must process.
> 
> I find the conceptual model of behave-nat-udp, which focuses
> on functions NATs might perform rather than classifications 
> of NATs as particular taxonomic entities (Basic, Full Cone, 
> etc), to be very attractive. That much said, I do agree with 
> several commentators that the resulting functional 
> descriptions lead to some very wordy terminologies. There 
> seems to be some emerging agreement on shorter terms, and I 
> think that would be most welcome to readers.
> 
> Regarding the terms used in behave-nat-udp versus
> ford-behave-gen, I see no immediate problems with the terms 
> used in behave-nat-udp. The distinction between a "map", a 
> "binding" and a "NAT session" in ford-behave-gen makes me a 
> little dizzy, to be honest. I do not find the definition of 
> "mapping" in behave-nat-udp to be problematic. I don't find 
> the use of the term "session" to refer to a transport-layer 
> connection between two endpoints to be problematic. 
> Terminology can be endlessly debated, but it is not clear to 
> me that we will gain much leverage on our problem space by 
> spending a few more cycles refining these terms.
> 
> In Section 4.1, I think it reasonable to define behaviors
> such as "External NAT mapping is endpoint address dependent" 
> just in order to disallow them in the requirements section. I 
> think it is worth being specific about things that we don't 
> want implementers to do.
> 
> Given the conceptual model of behave-nat-udp, I think the
> distinction between "deterministic" and "non-deterministic" 
> NATs in Section 8 is valuable. In fact, I think this 
> non-determinism is one of the primary grounds to move away 
> from a taxonomic model of NATs and into the functional model 
> espoused by behave-nat-udp. I didn't find Section 8 to be 
> particularly obscure when I read it, though no doubt the text 
> could be made more focused.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: [email-masked]
Date: Mon, 23 May 2005 15:36:53 -0700 (PDT)

I had a discussion with our engineering team on
the new proposal by Francois on REQ-7 this morning.
We basically agree with his proposal.
First off, some typos we found on the new REQ-7:
"transperencyIt" -> "transparency, it"
"ti was lucky" -> "it was lucky"
"could infere" -> "could interfere"
"one than one port" -> "more than one port"
I am not confident if I understand following statement
correctly. Could you please elaborate for me?
"however, such a policy could interfere with applications that use more 
than one port."

Besides the security point of view, avoiding endpoint
address port dependent filtering has another significant
benefit. If the two hosts (A and B) are behind different
NATs where:
- Host A is behind Full-cone or Restricted-cone NAT.
- Host B is behind Symmetric NAT.
(sorry for the use of old terminology)
ICE can find connectivity between the two in this case,
where if Host A is behind a Port-restricted cone NAT, ICE
will not be able to find a direct connectivity between them.
This could be mentioned in the REQ-7 justification section
for more specific clarification..?
I still think the inbound packet filtering is ideally a
firewall matter. However, I have to admit that it has been
implemented as a NAT feature and Behave needs to address it.
Having both endpoint independent and dependent RECOMMENDED
leaves it at NAT vendors discretion, which can
be viewed as essentially the same thing as I proposed.
I also pointed out that address independent helps
simplifying an application. As pointed out by Christian,
Bryan and Francois, address dependent NAT will not go away
in the foreseeable feature anyways, and I agree that address
independent filtering does not simply an application at
any point, so it was pointless in this dialog.
I would like to express my thanks to Bryan for raising
the issue with original REQ-7 and others for lots of
input and considerations in this regard.
- Yutaka

Francois Audet wrote:
Thanks to all,

------------------------

       (because the external endpoint could in reality be two endpoints 
behind
       another NAT, where one of the two endpoints is an attacker): 
however, such

---------------------

Wordy terminology:
  As for the wordy terminology for some of the names of behaviors, I 
also agree
  (the reasons for wordy names are historical). I can go through the 
text and simplify.

------------------------

REQs in-line:
  Bryan feels strongly about copying/pasting the REQs from section 12 
in-line in the
  text as they occur, to help the reader. I personally think it is a 
reasonable
  suggestion. Is there any STRONG objection to this? (Cullen in 
particular, I'd like to
  hear from you).

Determinism:
  I propose that to address Bryan's concern, I put a note in section 4.1 
and 5.1
  refering to the Deterministic behavior section. I also propose to 
change the first
  sentence of section 8 to the following:
    The classification of NATs is further complicated by the fact that 
under some
    conditions the same NAT often exhibits different behaviors, 
especially for
    mapping and filtering.

 > could be made more focused.
------------------------------------------------------------------------

---

From: Bryan Ford <[email-masked]>
Date: Wed, 25 May 2005 09:08:22 -0700 (PDT)

Hi Francois,

> This is a formal proposal on how to move forward, with concrete text.

Excellent - thanks.

As per the subsequent discussion involving Jon Peterson, I would prefer the 
stronger wording that explicitly says NATs SHOULD implement both 
Endpoint-Independent and Address-Specific Filtering and SHOULD default to 
Endpoint-Independent.

However, I find your proposed justification text perfectly reasonable (with 
the typo fixes suggested by others).

Just to clarify my proposal and make it more concrete, let's arbitrarily take 
Section 4.2 (Port Parity), since it's short, as an "example" section; here's 
how I envision this editorial change might make it look:

---

4.2.2  Port Parity

   Some NATs preserve the parity of the UDP port, i.e., an even port
   will be mapped to an even port, and an odd port will be mapped to an
   odd port.  This behavior respects the RFC 3550 [8] rule that RTP use
   even ports, and RTCP use odd ports.  Some NATs preserve the parity of
   the UDP port, i.e., an even port will be mapped to an even port, and
   an odd port will be mapped to an odd port.  This behavior respects
   the RFC 3550 rule that RTP use even ports and RTCP use odd ports when
   the application takes a single port number as a parameter and derives
   the RTP and RTCP port pair from that number.  RFC 3550 allows any
   port numbers to be used for RTP and RTCP if the two numbers are
   specified separately, for example using RFC 3605 [9].  However, some
   implementations do not include RFC 3605 and do not recognize when the
   peer has specified the RTCP port separately using RFC 3605.  If such
   an implementation receives an odd RTP port number from the peer
   (perhaps after having been translated by a NAT), and then follows the
   RFC 3550 rule to change the RTP port to the next lower even number,
   this would obviously result in the loss of RTP.  NAT-friendly
   application aspects are outside the scope of this document.  It is
   expected that this issue will fade away with time, as implementations
   improve.  Preserving the port parity allows for supporting
   communication with peers that do not support explicit specification
   of both RTP and RTCP port numbers.

   REQ-4  It is RECOMMENDED that a NAT have a "Port parity preservation"
          behavior of "Yes".

   Justification for REQ-4:
          This is to avoid breaking peer-to-peer applications which do
          not explicity and separately specify RTP and RTCP port numbers
          and which follow the RFC 3550 rule to decrement an odd RTP
          port to make it even.  The same considerations as per the IP
          address pooling requirement apply.

---

Then the text of REQ-4 above again reappears verbatim in the checklist in 
section 12 (i.e., the requirements are copied/pasted).  The justification 
text, however, (currently in section 12.1 of the udp) is _moved_ in-line as 
shown above and section 12.1 disappears from the draft.  Of course, once the 
justification paragraphs are placed in-line some of them may turn out to be 
overly redundant with the regular in-line body text they are next to and need 
further editing.

In any case, I'm not terribly concerned with the specific formatting, 
placement, or editing details of how this change is made, and happily leave 
those details to Francois - the above text is only meant to be an 
illustrative example, not a formal template.

This seems like a reasonable compromise.  (Yay.)

Cheers,
Bryan