Subject: [Ietf-behave] New drafts

From: Bryan Ford <[email-masked]>
Date: Thu, 17 Feb 2005 08:27:56 -0800 (PST)

Hi folks,

If you don't mind me interrupting the SCTP debate, there are three new 
BEHAVE-related drafts available at the ietf's Internet-Drafts archive.  
Unfortunately the IETF Secratariat may not forward the "official" 
availability announcement to this list because I forgot to ask them to in my 
submission. :(  The first one is as follows; I'll announce the others in 
separate messages...

"Design Principles and General Behavioral Requirements for Network Address 
Translators (BEH-GEN)"
http://www.ietf.org/internet-drafts/draft-ford-behave-gen-00.txt

Abstract:
    This document discusses design principles and behavioral properties 
required to make Network Address Translators (NAT) more predictable and 
compatible with diverse application protocols. First, this document presents 
a concrete architectural model for NAT devices and defines important terms 
used in conjunction with NAT design. This architectural model sets the stage 
for a set of concrete recommendations for NAT implementors and vendors, as 
being contemplated by the BEHAVE working group. The recommendations made by 
this document are independent of transport protocol; a set of companion 
documents provide behavioral recommendations specific to particular transport 
protocols.

The intent of this draft is to fill the current "gap" between the current UDP 
behavior draft (draft-ietf-behave-nat-udp-00.txt) and the preliminary TCP 
draft (draft-sivakumar-behave-nat-tcp-req-00.txt), by defining general 
principles, terminology, and specific NAT behavioral requirements that are 
transport-independent or at least common to both TCP and UDP.  At the moment 
the initial TCP draft is having to make awkward cross-references to parts of 
the UDP draft to talk about such common behavioral requirements, making it 
unclear precisely what parts of the UDP document are also supposed to apply 
to TCP and what parts are not.  And there's currently no place at all for 
requirements like, "NATs MUST support both TCP and UDP".

To fix these problems, I've taken the transport-independent portions of the 
UDP document, and transplanted them (with considerable editing) into this new 
"general principles" draft, along with some new content that hasn't appeared 
yet in either draft.  The intent is that the transplanted sections from the 
original UDP draft can then be removed or trimmed drastically, and both the 
UDP and TCP documents can simply refer to the common transport-independent 
document, without the TCP document having to make frequent awkward 
cross-references to the UDP document.

The specific sections of the original UDP draft that I'm proposing to move 
into the "general" document in this way are:

4.1  Address and Port Mapping
5.1  Filtering of Unsolicited Packets
7.  Hairpinning Behavior
10.  ICMP Behavior

(#10, ICMP Behavior, doesn't yet appear in the General draft because I ran out 
of time.)

If the BEHAVE group accepts the proposed document organization, then at least 
the General and UDP documents would probably need to be published together 
first, but the other related documents could still be published later in 
their own time as outlined in the original working group schedule.  Now that 
we have working drafts for UDP, and TCP, however, it might be worth at least 
considering the option of trying to push them through together, in order to 
ensure consistency and coherent organization.  But I'm also sympathetic to 
the reality that "IETF NAT documents are historically hard to publish", and 
that we shouldn't hold all the documents back unnecessarily if one or two 
prove particularly controversial.  (It's pretty clear that TCP and UDP 
shouldn't wait for a consensus to develop on SCTP, for example. :))  I'm 
mainly just proposing that, however and whenever we publish these various 
documents, we should at least work on them together with a goal of making 
them mutually consistent and well-organized, and that's what the proposed 
"Design Principles and General Requirements" draft is about.

Comments and reactions appreciated.

Thanks,
Bryan

---

From: Senthil Sivakumar <[email-masked]>
Date: Mon, 28 Feb 2005 15:34:32 -0800 (PST)

I think this is an useful effort mainly because a lot of port and
address binding behavior is common to both TCP and UDP.
We realized this when writing our TCP draft and hence there
are a lot of references to unicast UDP draft. Having a generic
draft that addresses the common requirements to both TCP
and UDP is good.
Some comments on the specifics.

Some comments.

Section 1.1 Applicability statement.

The paragraph
"Many enterprise NATs have special requirements for security,
multihoming and so forth, which may impose restrictions on the NAT's
behavior.  Such extra requirements are outside the scope of this...<snip>"
I would suggest that removing this paragraph since it suggests that
this draft recommends certain requirements that may not fit
into enterprise NAT requirements, but I didnt see anything specific
that would prevent enterprise networks from adopting this draft
as a general behavior..
Address Maps Table:

      The "Address Maps" table represents the NAT's static configuration
      database, which is controlled more-or-less directly by the user or
      network administrator.  The Address Maps table determines the type
      of NAT functionality the device implements, for example, such as
      Basic NAT, NAPT, Bidirectional NAT, Twice-NAT, or a combination
      thereof.  The Address Maps table also contains any permanent
      mappings the user may have configured between IP addresses or
      endpoints on the External and Internal realms: for example, a
      mapping between port 80 on the NAT's public IP address and a
      particular Web server located on the internal network.
I think the name Address maps table should be changed to Static map table.
This would include,
1. Static Address bindings.
2. Static port bindings.
3. Static port to application mapping (for example look for FTP in a port 
number
other than 21, say 2021).
4. Table that holds information on ALGs turned on by network admin.

I am a little unclear on this para
"One possible design approach that is specifically forbidden, however,
is to use IP-level or higher-level packet contents to distinguish between ..."
as to why you particularly forbid doing NAT based on IP addresses. How do
you expect NAT to happen in one-armed routing case, where there is only
one physical interface (There may be a logical port though).. Also, when
you say an internal and external interface is identified below IP layer, how
do you classify the explicitly classified ports as internal and external? Also,
after classifying the ports/interfaces as internal and external, is it ok 
to now
to make a decision to NAT only based on IP address. I think this is a crucial
feature that a lot of people are using today and I don't see any reason why
it should be forbidden. Also, as long as a NAT has intelligence to clearly
identify the internal and external realms, why should we force a restriction?

REQ-2 should also include ICMP in addition to the other protocols mentioned.
Even though it does not fall into the transport protocols category it is an 
integral
part of any NAT implementation. If you think we want to keep it separately that
is fine too..

Minor one.

Why is REQ-4 RECOMMENDED but not a MUST. I think it should be a must
because with the non-paired source address causes inconsistent behavior of
NATs arbitrarily assigning addresses.
DHCP configured NATs.

I think this section is beyond just DHCP, because other mechanisms like
dial up can be used to obtain the upstream IP address. Also this should be
beyond the scope of this document, IMO. We should just state that it
is the responsibility of the admin to make sure they avoid mis-configurations
of NAT.
I suggest the REQs 8 & 9 be removed but stated as general recommendations
but not as NAT requirements. The reason is it is beyond NAT and involves other
protocols such as DHCP but not limited to DHCP alone..
Thanks
Senthil
At 05:27 PM 2/17/2005 +0100, Bryan Ford wrote:
Hi folks,

The intent of this draft is to fill the current "gap" between the current 
UDP
(#10, ICMP Behavior, doesn't yet appear in the General draft because I ran 
out
of time.)

Thanks,
Bryan
_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Bryan Ford <[email-masked]>
Date: Tue, 1 Mar 2005 04:12:21 -0800 (PST)

Hi Senthil,

Thanks for your comments - responses inline.

> that would prevent enterprise networks from adopting this draft

This text was originally derived from the behave-udp draft by Francois and 
Cullen.  I'm OK with removing it, and I think someone else suggested doing so 
too, but perhaps Francois or Cullen would like to comment?

> 4. Table that holds information on ALGs turned on by network admin.

I'm OK in principle with this suggestion, but I'm a bit leery about going into 
too much detail about what exactly a NAT's static configuration database 
contains (or should contain), as it seems to be wandering at least 
dangerously close to out-of-scope for what we're trying to accomplish.

> one physical interface (There may be a logical port though)..

In my understanding, one-armed routing is typically done by using 802.11Q VLAN 
tags to multiplex multiple logically separate Ethernet segments onto a single 
physical interface, and the NAT or router then routes or NATs between those 
separate Ethernet segments.  As the text of the draft points out, this 
"standard" one-armed routing scenario is fine.  But if the NAT has _no_ way 
to distinguish the two "sides" other than by IP addresses alone, it's likely 
to create (a) massive security holes because hosts on either side can easily 
forge packets that look like they came from the opposite side, and (b) 
massive confusion in general if the IP address domains on the two sides of 
the NAT numerically overlap.

> REQ-2 should also include ICMP in addition to the other protocols
> mentioned. Even though it does not fall into the transport protocols
> category it is an integral
> part of any NAT implementation. If you think we want to keep it separately
> that is fine too..

Yes, I'm fine with including ICMP in REQ-2.

> NATs arbitrarily assigning addresses.

I don't think REQ-4 necessarily needs to be a MUST as long as REQ-3 is a MUST, 
because it is REQ-3 that enables applications to predict the port numbers it 
needs to use for hole punching purposes.  For example, if a NAT supports 
REQ-3 but not REQ-4, and an application on node A communicates from two local 
endpoints A:a1 and A:a2, then the NAT might translate A:a1 to public endpoint 
B:b and might translate A:a2 to public C:c (not only different public port 
numbers but different IP addresses).  But that doesn't cause any problem for 
hole-punching applications because the application has to anticipate that its 
two original port numbers a1 and a2 will be translated to two different 
public port numbers in an unrelated and unpredictable fashion anyway.  Since 
the NAT-friendly application can't expect to control the NAT's assignment of 
its precise public endpoints anyway, why should it care whether its two 
public endpoints happen to have the same public IP address?

> dial up can be used to obtain the upstream IP address.

But "dial up" mechanisms usually use DHCP somewhere underneath, don't they?  
At least my impression was that PPP-based dial-up protocols usually first set 
up a tunnel for IP packets and then use DHCP to assign the dial-up node its 
IP address and other network-layer parameters.  I'm not extremely familiar 
with the operation of dial-up protocols, though, so I could be wrong, and if 
so the wording of this section should indeed be generalized to include them 
explicitly.

> Also this should be 
> is the responsibility of the admin to make sure they avoid
> mis-configurations of NAT.

Unfortunately, as our "topologies" document discusses in greater detail, 
it is very often the case that overlapping private IP address regions are 
unavoidable even if all the system administrators involved know what they're 
doing.  The problem is that the NAT often (nay, _usually_) falls exactly on 
an administrative boundary, and the administrator who manages the private IP 
address realm on one side of the NAT is different from the administrator who 
manages the private IP address realm on the other side.  Neither can 
necessarily control what the other one does, and in the common case where the 
"downstream" administrator is an ordinary clueless user deploying a 
consumer-level DHCP-configured NAT, there's no way the user can be expected 
to know how to configure his NAT so as to avoid his private "downstream" IP 
address space conflicting with his ISP's private "upstream" IP address space.  
The NAT itself has to deal with this problem somehow if we ever want it to 
work reliably in increasingly-common multi-level NAT scenarios.  (In fact I've 
recently received E-mail from someone who was bitten by this precise 
problem.)

> but not as NAT requirements. The reason is it is beyond NAT and involves
> other protocols such as DHCP but not limited to DHCP alone..

I don't agree in this case, for the reasons stated above - but I do realize 
that this section pushes the current boundaries of what has been discussed so 
far on the BEHAVE list and in related documents, and other people are likely 
to have different ideas on this topic as well.  For that reason I'd very much 
like to see more discussion on the BEHAVE list about this topic.

Thanks,
Cheers,

> >availability announcement to this list because I forgot to ask them to in
> > my submission. :(  The first one is as follows; I'll announce the others
> > in separate messages...
> >
> >
> >compatible with diverse application protocols. First, this document
> > presents a concrete architectural model for NAT devices and defines
> > important terms used in conjunction with NAT design. This architectural
> > model sets the stage for a set of concrete recommendations for NAT
> > implementors and vendors, as being contemplated by the BEHAVE working
> > group. The recommendations made by this document are independent of
> > transport protocol; a set of companion documents provide behavioral
> > recommendations specific to particular transport protocols.
> >
> >
> > UDP behavior draft (draft-ietf-behave-nat-udp-00.txt) and the preliminary
> > TCP draft (draft-sivakumar-behave-nat-tcp-req-00.txt), by defining
> > general principles, terminology, and specific NAT behavioral requirements
> > that are transport-independent or at least common to both TCP and UDP. 
> > At the moment the initial TCP draft is having to make awkward
> > cross-references to parts of the UDP draft to talk about such common
> > behavioral requirements, making it unclear precisely what parts of the
> > UDP document are also supposed to apply to TCP and what parts are not. 
> > And there's currently no place at all for requirements like, "NATs MUST
> > support both TCP and UDP".
> >
> >To fix these problems, I've taken the transport-independent portions of
> > the UDP document, and transplanted them (with considerable editing) into
> > this new "general principles" draft, along with some new content that
> > hasn't appeared yet in either draft.  The intent is that the transplanted
> > sections from the original UDP draft can then be removed or trimmed
> > drastically, and both the UDP and TCP documents can simply refer to the
> > common transport-independent document, without the TCP document having to
> > make frequent awkward cross-references to the UDP document.
> >
> >If the BEHAVE group accepts the proposed document organization, then at
> > least the General and UDP documents would probably need to be published
> > together first, but the other related documents could still be published
> > later in their own time as outlined in the original working group
> > schedule.  Now that we have working drafts for UDP, and TCP, however, it
> > might be worth at least considering the option of trying to push them
> > through together, in order to ensure consistency and coherent
> > organization.  But I'm also sympathetic to the reality that "IETF NAT
> > documents are historically hard to publish", and that we shouldn't hold
> > all the documents back unnecessarily if one or two prove particularly
> > controversial.  (It's pretty clear that TCP and UDP shouldn't wait for a
> > consensus to develop on SCTP, for example. :))  I'm mainly just proposing
> > that, however and whenever we publish these various documents, we should
> > at least work on them together with a goal of making them mutually
> > consistent and well-organized, and that's what the proposed "Design
> > Principles and General Requirements" draft is about.
> >

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 1 Mar 2005 08:12:15 -0800 (PST)

> too, but perhaps Francois or Cullen would like to comment?

This text happened out of a discussion that happened in one of the WG
meetings. Greg Leovitz was one of the key people at the microphone. The
essence of the discussion was that there are very good reasons to build
security devices that violate the rules in the behave documents. For
example, you might want if Host A inside the NAT forms UDP connection to two
different external places, the external places can not tell that both
requests came from A. Now a NAT that did that would not be behave compliant.
However, it is a fine thing to build. What we need to somehow capture is
that behave compliant allows a certain set of things - however there are
good reasons that a device might choose not to be behave compliant. What
vendors could not live with is that if our documents said they could not
claim their devices was behave compliant just because it had configurable
features that made it non compliant when used.

Am I making any sense?

Cullen (not as chair)