Subject: RE: [Ietf-behave] Req-7 draft-ietf-behave-nat-udp-01.txt

From: "Francois Audet" <[email-masked]>
Date: Tue, 17 May 2005 14:10:28 -0700 (PDT)

Guys,

The current draft actually does RECOMMEND "Address restricted cone".

I'm hearing support from both of you for the current RECOMMENDATION.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Christian Huitema
> Sent: Tuesday, May 17, 2005 10:00
> To: Cullen Jennings; Bryan Ford; Behave; audet@xxxxxxxxxxxxxxxxxx
> Subject: RE: [Ietf-behave] Req-7 draft-ietf-behave-nat-udp-01.txt
> 
> 
> > However, which of us is right or wrong about the security 
> implications 
> > here turns out to probably be totally irrelevant. I phoned my 
> > colleagues at Linksys this morning and asked if they would do this. 
> > When they
> stopped
> > laughing at me they told me no way. If they did this, netgear and
> dlink
> > would claim their NATs were more secure than linksys NATs and they
> would
> > get
> > toasted in the market. They are not going to do full cone. I imagine
> your
> > own testing shows the number of full cone NATs in the market is a)
> fairly
> > small and b) becoming more rare. My testing indicates this.
> 
> On the other hand, the same folks would have a problem if, 
> say, X-Box games did not work through their products but 
> worked well through the competition's offers. So, obviously, 
> there has to be a compromise.
> 
> The emerging consensus seems to be along the line of "address 
> restricted cone". It enables replies to an UDP port from 
> addresses to which a packet has already been sent, and it 
> also enables multi-party sessions. It accounts for the fact 
> that replies sometimes come from a different UDP. It blocks 
> traffic sent by random sources, and thus offer a reasonable 
> degree of protection.
> 
> -- Christian Huitema _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 17 May 2005 14:14:47 -0700 (PDT)

To reiterate both Christian's and Cullen's points, lots of applications (like
SIP phones) also behave like an address restricted cone NAT (from a filtering
point of view) in that they don't use connected sockets, but still check 
for the IP address of the far end to match what it expects. For the same 
reasons Christian highlights.

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 17 May 2005 20:45:16 -0700 (PDT)

Saikat Guha wrote: 
> On Tue, 2005-05-17 at 09:59 -0700, Christian Huitema wrote:
restricted
> > cone". It enables replies to an UDP port from addresses to which a
> > packet has already been sent, and it also enables multi-party
sessions.
> 
> Just curious -- does this hold for TCP as well? Existing NATs are
> predominantly "restricted" (both address and port) for TCP though we
did
> notice some "address restricted" ones.

I personally do not expect peer-to-peer TCP to work through NAT. I
cannot convince myself that any of the proposed TCP solutions is
practical. In any case, I consider establishing TCP connections a
different problem than allowing UDP associations.

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 17 May 2005 21:26:41 -0700 (PDT)

> different problem than allowing UDP associations.

Well, I wrote this before reading the paper that Saikat and Paul
published. Their experiment shows that a combination of simultaneous TCP
openings and port prediction may very often succeed establishing
peer-to-peer TCP connections through NAT, which is quite interesting.
Still, this is a different problem than allowing UDP associations...

-- Christian Huitema

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 20 May 2005 13:50:02 -0700 (PDT)

Exactly.

For 7 to make life easier for implementros, it would have to say 
        A NAT MUST have an "External filtering is endpoint independent".

> From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] 
> Sent: Friday, May 20, 2005 13:08
> To: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx; Bryan Ford
> Cc: Behave; audet@xxxxxxxxxxxxxxxxxx
> Subject: Re: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt
> 
> 
> 
> I don't see how Brian's proposal helps application 
> developers. Let say that a NAT has been configured to do 
> address dependant filtering, the application still supposed 
> to work. We are trying to make a system where applications 
> can work with any behave compliant NAT. That means the 
> application needs to assume the "worst case". Unless we 
> change Req-7 to say that a NAT MUST NOT filter based on the 
> the address or port, we don't make life any easier for the 
> application developer.
> 
> On 5/19/05 9:08 PM, "yutaka_takeda@xxxxxxxxxxxxxxxxxxxx"
> <yutaka_takeda@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > 
> > I agree with Bryan's opinion with following three reasons:
> > 
> > 1) NAT should do just what it is supposed to do. If the
> > port overloading is not required, then the "external 
> filtering" is no 
> > longer a NAT's job. "It sounds more secure.." as more of a 
> sales talk
> > just does not sound right to be a basis of a decision
> > made by IETF. Filtering behavior should have something
> > to do with users' security policy, which is exactly what
> > Bryan is suggesting.
> > 
> > 2) Endpoint independent maintains full UDP functionality. Endpoint 
> > address dependent filter compromises natted node's ability 
> to receive 
> > packet from anyone. This seems to be a huge loss for the Internet 
> > community, for the sake of halfway security measures. 
> Probably this is 
> > likely a thing that people who only has VoIP in mind do not care
> > about.
> > 
> > 3) Avoid ICE to be an requirement for traversing NAT
> > As a programmer, the simplest solution is preferable.
> > ICE is way far from 'simple'. Endpoint dependent filter behavior 
> > requires ICE connectivity check process or equivalent (UDP hole 
> > punching by knowing the other end's transport address). Just for a 
> > reminder for us...
> > 
> > So, I strongly support:
> > 
> >>     REQ-7: NATs MUST implement Endpoint-Independent
> >>            Filtering in their default configuration.
> >>            NATs SHOULD be configurable to support
> >>            Address-Specific Filtering or Endpoint-Specific 
> Filtering
> >>            at the option of the system administrator.
> > 
> > - Yutaka
> > 
> > 
> > 
> > Bryan Ford wrote:
> >> On Tuesday 17 May 2005 12:41, Cullen Jennings wrote:
> >> 
> >>> We are really only discussing if we recommend that the 
> filtering is 
> >>> restrictive or not here. Somewhere you pointed out this 
> is falling 
> >>> into the firewall area and may not even be relevant for BEHAVE to 
> >>> specify and I think I agree with you on that. At one point we had 
> >>> that but got strong feedback form implementers, please recommend 
> >>> (but don't mandate) something as they want to know what to do. We 
> >>> certainly want Full Cone NAT to be behave compliant. 
> However, what 
> >>> you are proposing is making it such that a NAT with only 
> Restricted 
> >>> filtering would *not* be behave compliant.
> >> 
> >> 
> >> Not true - please refer again to my specific proposal:
> >> 
> >>     REQ-7: NATs MUST implement Endpoint-Independent
> >>            Filtering in their default configuration.
> >>            NATs SHOULD be configurable to support
> >>            Address-Specific Filtering or Endpoint-Specific 
> Filtering
> >>            at the option of the system administrator.
> >> 
> >> Notice *"in their default configuration"*.  Under this proposal, a 
> >> NAT that does Restricted filtering is still BEHAVE 
> compliant *if* the 
> >> administrator configures it as such.  My proposal in fact 
> >> specifically recommends that NAT vendors implement Restricted 
> >> filtering as a configuration option, and since most NATs already 
> >> support it we can assume that it will be a pretty standard 
> security 
> >> option.  But the operative word here is *option*.  A NAT 
> in its "out 
> >> of the box" configuration shouldn't impose firewall functionality 
> >> that severely interferes with the capabilities of applications, as 
> >> restricted filtering does.
> >> 
> >> 
> >>> I strongly disagree with this proposal.
> >>> 
> >>> I understand your security argument below however I think it is 
> >>> wrong. A large portion of application that use UDP do not do 
> >>> connected UDP.
> >> 
> >> 
> >> That's because a "large portion of application[s] that use 
> UDP" use a 
> >> single UDP port to talk to multiple external endpoints, usually 
> >> because they want to engage in peer-to-peer-style communication in 
> >> some form with other peer hosts.  And it is precisely this "large 
> >> portion" of UDP applications that needs endpoint-independent 
> >> filtering the most.
> >> 
> >> 
> >>> Furthermore, the outside firewall that does this type of 
> behavior is 
> >>> protecting the resources on the internal network from 
> being consumed 
> >>> forwarding bogus packets even if the eventual end 
> application will 
> >>> correctly discard them. We can not define behave such 
> that a behave 
> >>> compliant NAT could not also be a fairly normally configured 
> >>> firewall.
> >> 
> >> 
> >> First of all, even with endpoint-independent filtering, a 
> NAT will in 
> >> practice filter out the vast majority of bogus traffic 
> that reaches 
> >> it - the only bogus traffic it will let through is bogus 
> traffic that 
> >> happens to hit the specific external port number that 
> corresponds to 
> >> an active port binding, and that is not likely to happen too often 
> >> because these port numbers are assigned more-or-less 
> randomly by the 
> >> NAT and only in the high, non-well-known port number space.  The 
> >> incremental benefit of restrictive filtering on random 
> bogus traffic 
> >> is going to be very small.
> >> 
> >> An attacker might deliberately send bogus to a bound NAT 
> port known 
> >> to be in use, but if the attacker can find out which NAT port the 
> >> application is using, then the attacker probably also 
> knows (or can 
> >> easily find out or
> >> guess) the address and port number of the remote host that 
> the application is
> >> talking to and just spoof that source IP address and port 
> number in its
> >> attack packets, getting around Restricted filtering as 
> well.  In fact the
> >> remote host's endpoint is in practice likely to be much 
> easier for the
> >> attacker to find out or guess than the application's 
> public NAT port, because
> >> of the overwhelming prevalence of well-known servers and 
> ports on the
> >> Internet.  So the practical benefit that Restricted 
> filtering provides even
> >> against directed attacks is still minimal.
> >> 
> >> Finally, the goal of "protecting the resources on the internal 
> >> network from being consumed forwarding bogus packets" is 
> really only 
> >> a consideration on large corporate or ISP networks with 
> substantial 
> >> internal traffic load, and if this minimization of 
> resource use is a 
> >> concern then the network administrator can certainly be 
> expected to 
> >> know how to configure the company's NAT to enable Restricted 
> >> filtering.  As I pointed out above, under my proposal a 
> NAT can use 
> >> Restricted filtering and still be BEHAVE-compliant as long 
> as it is 
> >> the administrator (not the NAT vendor) that enables this firewall 
> >> behavior.
> >> 
> >> For home NATs, in contrast, minimizing resource load on 
> the internal 
> >> network due to bogus traffic is completely a non-issue because the 
> >> home network (Ethernet or 802.11 or whatever) is typically so much 
> >> faster than the Internet uplink anyway.  In this case it's 
> much more 
> >> important that NATs consistently support applications 
> well, which my 
> >> proposal ensures by requiring that the NAT's "out of the box" 
> >> configuration is Endpoint-independent Filtering.  Joe Clueless who 
> >> buys a home NAT router probably doesn't have any idea what NAT 
> >> actually is, but he wants his applications to work.
> >> 
> >> 
> >>> implications here turns out to probably be totally irrelevant. I 
> >>> phoned my colleagues at Linksys this morning and asked if 
> they would 
> >>> do this. When they stopped laughing at me they told me no way. If 
> >>> they did this, netgear and dlink would claim their NATs were more 
> >>> secure than linksys NATs and they would get toasted in 
> the market. 
> >>> They are not going to do full cone. I imagine your own 
> testing shows 
> >>> the number of full cone NATs in the market is a) fairly 
> small and b) 
> >>> becoming more rare. My testing indicates this.
> >> 
> >> 
> >> How did you ask the question?  Any marketing person worth 
> his monthly 
> >> paycheck will be able to figure out that a NAT following 
> my proposed 
> >> recommendations can be presented as:
> >> 
> >> * JUST AS SECURE as everyone else's NAT because it 
> implements all the 
> >> same security features (including Restricted filtering, as a 
> >> configurable option).
> >> * MORE APPLICATION-FRIENDLY than the next guy's NAT 
> because it allows
> >> applications to have a first-class "Internet presence", 
> and the other guy's
> >> (non-configurable Restricted Cone NAT) doesn't.
> >> 
> >> With this approach I'm sure any NAT that wasn't BEHAVE-compliant 
> >> would quickly get toasted in the market.
> >> 
> >> Besides, is it our job to bow to every existing NAT market 
> tendency, 
> >> good or bad, or is to set a standard for how NATs _should_ (and 
> >> reasonably can) behave in order to work well with applications?
> >> 
> >> Cheers,
> >> Bryan
> >> _______________________________________________
> >> Ietf-behave mailing list

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 20 May 2005 13:58:54 -0700 (PDT)

Right.

To me, this is only going to work if it is Endpoint independent.

> From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx 
> [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx] 
> Sent: Friday, May 20, 2005 11:40
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'Bryan Ford'; 'Cullen Jennings'; 'Behave'
> What I meant by saying "ICE or equivalent" is a system that
> operates:
> 
> 1) Initiator grabs external transport address on the NAT on
>     every event of session initiation.
> 2) Inform the other end of the address via a proxy server.
> 3) The other end (Acceptor) grabs its external transport
>     address on the Acceptor's NAT.
> 4) Inform the initiator of the external address.
> 5) Preform UDP hole punching from both ends to the transport
>     addresses obtained. (This is done by connectivity check
>     in ICE.)
> 
> and this operation is required to every node including
> ability to use the proxy server.
> 
> Imagine, if a node behind an Endpoint Independent NAT
> wishes to receive packets from anywhere (like a server),
> the node simply sends a binding request to STUN server
> to grab an external port on the NAT, and the port is
> available ahead of time for anyone without the above
> operation.
> 
>  > Does the application you have in mind requires receiving 
> packets  > from "unknown" places?
> 
> Yes, hopefully with a simple way. Currently UPnP is the
> only way that allows this.
> 
>  > I assume the application then has to have
>  > it's own way of securing itself based on some other 
> criteria than  > the source of the packets?
> 
> Yes, as well as the application used to have a global
> address needed to do, and as an UDP/IPv6 application
> that likely does not require a NAT.
> 
> 
> - Yutaka
> 
> 
> 
> Francois Audet wrote:
> > Hi Yutaka,
> > 
> > Thanks for your input.
> > 
> > I'm not sure I understand why you think you need to do ICE with 
> > Address dependent (or Address and port dependent as a 
> matter of fact). 
> > In both cases, you don't but in both cases, you need to send some 
> > outgoing packets before you can start receiving any.
> > 
> > With Endpoint Independent you have to have sent packets 
> outside of the 
> > NAT from the source port to anywhere to start receiving 
> from anywhere.
> > 
> > With Address dependent, you have to have sent packets 
> outside of the 
> > NAT to the IP address that is sending you packet to the source.
> > 
> > With Address and port dependent, you have to have sent 
> packets outside 
> > of the NAT to the IP address and port that is sending you 
> packets to 
> > the source.
> > 
> > None of these options requires ICE: just sending some 
> probes, without 
> > even waiting for responses.
> > 
> > In all cases you need to send a probe. The difference is do 
> you have 
> > to send it to 1 IP address, or to all IP address (and possibly
> > port) you want to communicate with.
> > 
> > Does the application you have in mind requires receiving 
> packets from 
> > "unknown" places? I assume the application then has to have 
> it's own 
> > way of securing itself based on some other criteria than 
> the source of 
> > the packets?
> > 
> > Anyways, some clarification would be appreciated.
> > 
> > Thanks.
> > 
> >  > -----Original Message-----
> >  > From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx
> >  > [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx]
> >  > Sent: Thursday, May 19, 2005 21:08
> >  > To: Bryan Ford
> >  > Cc: Cullen Jennings; Behave; audet@xxxxxxxxxxxxxxxxxx
> >  > Subject: Re: [Ietf-behave] Re: Req-7 
> > draft-ietf-behave-nat-udp-01.txt  >  >
> >  >
> >  > I agree with Bryan's opinion with following three reasons:
> >  >
> >  > 1) NAT should do just what it is supposed to do. If the
> >  > port overloading is not required, then the "external
> >  > filtering" is no longer a NAT's job.
> >  > "It sounds more secure.." as more of a sales talk
> >  > just does not sound right to be a basis of a decision
> >  > made by IETF. Filtering behavior should have something
> >  > to do with users' security policy, which is exactly what
> >  > Bryan is suggesting.
> >  >
> >  > 2) Endpoint independent maintains full UDP functionality.
> >  > Endpoint address dependent filter compromises natted node's
> >  > ability to receive packet from anyone. This seems to be a
> >  > huge loss for the Internet community, for the sake of halfway
> >  > security measures. Probably this is likely a thing that
> >  > people who only has VoIP in mind do not care about.
> >  >
> >  > 3) Avoid ICE to be an requirement for traversing NAT
> >  > As a programmer, the simplest solution is preferable.
> >  > ICE is way far from 'simple'. Endpoint dependent filter
> >  > behavior requires ICE connectivity check process or
> >  > equivalent (UDP hole punching by knowing the other end's
> >  > transport address). Just for a reminder for us...
> >  >
> >  > So, I strongly support:
> >  >
> >  >  >     REQ-7: NATs MUST implement Endpoint-Independent
> >  >  >            Filtering in their default configuration.
> >  >  >            NATs SHOULD be configurable to support
> >  >  >            Address-Specific Filtering or Endpoint-Specific
> >  > Filtering
> >  >  >            at the option of the system administrator.
> >  >
> >  > - Yutaka
> >  >
> >  >
> > 
> 
>