Saikat Guha | 1 Jun 12:15 2005
Picon

Re: Re: draft-ietf-behave-nat-udp-01, REQ-7

Just so we are on the same page, I define 'wildcard' as follows. Any
host can send a packet to the UDP service endpoint without first
communicating with some other host. For example, once a root DNS server
is up and running *any* host on the internet can query it and receive a
response without first communicating with any other host. 

On Mon, 2005-05-30 at 11:42 -0700, Pyda Srisuresh wrote:
> The next important thing is to make NATs application friendly, without
> violating the fundamental NAT behabior. [...] Cone NAT behavior varies
> with UDP sessions because even though the binding is unirectional, UDP
> sessions are not like TCP and can have wildcards on the destination
> address and port. Wildcard on the destination port alone makes it an
> Address restricted Cone NAT, where as wildcard on address & 
> port makes it a Full Cone NAT.

Indeed 'wildcard'-ing is essential for UDP, but Full Cone does NOT
support it. Full Cone is no more application friendly than Restricted
Cone.

Consider a UDP NAT wildcard scenario -- one wants to deploy a root DNS
server ... behind a NAT. Futher assume that the NAT is Full Cone. Even
so, you cannot do it. No matter what, there is NO way for a new host to
send a packet to the DNS server without interacting with some other host
first. Even if the NAT is Full Cone. Let me illustrate the point.

Host A --------- NAT N --------- Internet ---------- C
                                    |
                                    +--------------- B

- DNS server runs on A (UDP port 53).
(Continue reading)

Cullen Jennings | 1 Jun 03:39 2005
Picon

Re: TCP through NATs (was Re: How should NATs reject TCP packets?)

On 5/30/05 12:03 PM, "Pyda Srisuresh" <srisuresh <at> yahoo.com> wrote:

> Cullen,
> 
> Reset handling is also done in firewalls. That is not to say, Reset handling
> is
> a firewall issue. I disgaree with your remark that reet handling is a firewall
> only issue.

That's a fair comment - I did not mean to imply that we say nothing about
RST. What do you think we have to say about RST to make STUNT reliably work?
Are you in agreement with the conclusions that came up in last WG meeting?

> You mention WG meeting notes below. I dont recall seeign one one on the list.
> Were the WG meetign minutes mailed to the list already? If so, could you pint
> me to the mail that includes this. Thanks.

Not online right now but check around 3/7 or so. You can find them off the
auxiliary web page for the WG and by now I imagine they are in the minutes
from the last IETF.

Cullen <not as chair>

> 
> cheers,
> suresh
> 
> --- Cullen Jennings <fluffy <at> cisco.com> wrote:
> 
>> On 5/17/05 3:03 PM, "Saikat Guha" <sg266 <at> cornell.edu> wrote:
(Continue reading)

Cullen Jennings | 1 Jun 15:25 2005
Picon

Re: Re: draft-ietf-behave-nat-udp-01, REQ-7


I agree with Saikat reasoning and would be fine with his proposed text of.

> REQ-7:
>         It is RECOMMENDED that a NAT have an "Endpoint Address dependent
> filtering" behavior.

I think some other people might have objected to the "Endpoint" filtering at
some point but I did not. I could also be convinced to go with something
along the lines of Bryan's proposal of

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

We would need to restructure this slightly because I don't think we can
simultaneously RECOMMEND two contradictory things but I would be ok with
keeping he meaning the same. On the subpoint of

> a) The filtering behavior SHOULD be a user configurable option.

I could deal with this if we change to MAY but strongly object to the
SHOULD. There are going to be devices where this is difficult. There are
going to be devices that only support one type. In many case the
administrator of the NAT is very different from the user of it. There is no
reason why the WG should tell vendors how to build this. Having it as MAY or
SHOULD does not change any interoperability issues between devices. Any
standards body should focus on things that it needs to specify to ensure
interoperability. Once vendors start down the slipper slope of not being
(Continue reading)

Bryan Ford | 1 Jun 18:31 2005
Picon

Re: Re: draft-ietf-behave-nat-udp-01, REQ-7

On Wednesday 01 June 2005 09:25, Cullen Jennings wrote:
> > a) The filtering behavior SHOULD be a user configurable option.
>
> I could deal with this if we change to MAY but strongly object to the
> SHOULD. There are going to be devices where this is difficult. There are
> going to be devices that only support one type. In many case the
> administrator of the NAT is very different from the user of it.

Excellent point - in fact, your comment made me realize that the wording of 
the proposed recommendation above (suggested by Francois) does not quite 
match what I had in mind - what I actually want is more along the lines of:

 a) The filtering behavior SHOULD be an option configurable by the
    administrator of the NAT.

I completely agree that we can't expect the NAT's behavior to be configurable 
by the "end-user" (the bloke making connections through the NAT), when the 
end-user isn't the one who actually controls the NAT.  My intention (from the 
start) was only that this aspect of the NAT behavior should be configurable 
by whomever actually _does_ deploy and control the NAT.  In the case of 
ISP-deployed or corporate NATs, it should be configurable by the ISP's or 
company's network administrator, not necessarily by individual users of the 
company's network.  Similarly, in the case of low-end "locked" residential 
NATs that the ISP provides and controls exclusively, the ISP is effectively 
making itself the "administrator" of the NAT, and taking this power away from 
the end user.  Neither of these situations create any problems for the NAT 
being made configurable by the NAT's _administrator_ (e.g., the ISP), as per 
the revised wording above.

As Jon Peterson pointed out a while ago, the BEHAVE group's documents are 
(Continue reading)

Paul Hoffman | 1 Jun 23:41 2005

New TCP requirements draft

Greetings again. Now that looks like the UDP requirements document is 
going to be organized more along the "general NAT requirements first, 
UDP-specific requirements second" model, I thought it would be good 
to take a stab at a draft that had *only* TCP-specific requirements. 
Please see 
<http://www.ietf.org/internet-drafts/draft-hoffman-behave-tcp-00.txt>, 
which gets its definitions from the UDP requirements document.

This document is purposely quite short. The goal of this WG is to 
create documents that are easily understood by all NAT developers, 
not just the most technical ones (and not just the ones who like 
reading standards documents). To reach that goal, we need to limit 
the rationale descriptions to just enough for a developer to believe 
we have some reason for our requirements.

If I missed any TCP-specific requirements, I'm happy to revise the document.

--Paul Hoffman, Director
--Cybersecurity Association
--www.cybersecurity.org
Pyda Srisuresh | 2 Jun 16:14 2005
Picon

Re: Re: draft-ietf-behave-nat-udp-01, REQ-7

Hi Saikat,

I may not have been clear in my previous e-mail. Please see my explanation of
wildcarding below. 

Bi-directional NAT in general is more application friendly than Traditional
NAT. This is because the Bindings are bi-directional for Bi-directional NAT and
uni-directional for Traditional NAT. 

Full-Cone NAT degenrates into Bi-directional NAT, due to wildcarding employed
in the NAT Sessions for UDP.

Specific comments below inline.

cheers,
suresh

--- Saikat Guha <sg266 <at> cornell.edu> wrote:

> Just so we are on the same page, I define 'wildcard' as follows. Any
> host can send a packet to the UDP service endpoint without first
> communicating with some other host. For example, once a root DNS server
> is up and running *any* host on the internet can query it and receive a
> response without first communicating with any other host. 
>  
[suresh] There is a variation to this - wildcard on the IP address, and
wildcard on the UDP port.

Say, a host (A) in the private domain initiated a UDP session outbound to an
external endpoint B:b (B is the external address and b is the UDP port on B).
(Continue reading)

Pyda Srisuresh | 3 Jun 17:37 2005
Picon

Re: TCP through NATs (was Re: How should NATs reject TCP packets?)


--- Cullen Jennings <fluffy <at> cisco.com> wrote:

> On 5/30/05 12:03 PM, "Pyda Srisuresh" <srisuresh <at> yahoo.com> wrote:
> 
> > Cullen,
> > 
> > Reset handling is also done in firewalls. That is not to say, Reset
> handling
> > is
> > a firewall issue. I disgaree with your remark that reet handling is a
> firewall
> > only issue.
> 
> That's a fair comment - I did not mean to imply that we say nothing about
> RST. What do you think we have to say about RST to make STUNT reliably work?
> Are you in agreement with the conclusions that came up in last WG meeting?
> 
[suresh] Sure, I agree with the conclusions. We also had discussion on the list
about whether to silently drop the packets or generate RST/ICMP-reject for TCP.
Initially, we agreed that the NAT device SHOULD send ICMP destination
unreachable message, with a code of 10. This is what the ford-behave-gen draft
reflects currently in REQ-9. Later, we agreed to drop the packets silently. We
will revise the text in the next rev of behave-gen draft. 

As for RST processing, below is what the sivakumar-behave-nat-tcp draft says. I
donot see anything in this that impacts STUNT. 

   RST attack is another well known DoS attack. An attacker could
   simply forge a number of RST packets for a variety of Established
(Continue reading)

Peterson, Jon | 3 Jun 21:35 2005

RE: Re: draft-ietf-behave-nat-udp-01, REQ-7


> One more reason, why I believe, we need to treat behave-gen and behave-udp as
> two different drafts with different scopes and NOT combine them into one within
> the UDP draft. Any comments?

I do have one further comment on this. It has become increasingly clear to me that treating these as separate
drafts, with separate authors and terminology and ideas, is unlikely to be a path towards consensus. At
best, I think it would sweep certain differences under the rug. I think it is preferable, and possible, to
come to WG consensus about those differences. That should be done in the context of a single document.

Jon Peterson
NeuStar, Inc.

> cheers,
> suresh
Marc Manthey | 3 Jun 21:43 2005
Picon

opencuseeme

hello experts, sorry for  my  offtopic  post
due  to the massive  influence from tycoon firms,
apple for  example during  the miss use of vlanhacks
and the ongoing  software patents disscussion
in europe and the pressure from the
http://www.mpaa.org/ on bittorrent users
i think there is a strong need for  Opencuseeme
a free peer2peer multiconferencing tool.
please  join

regards
www.cuseeme.de

Attachment (smime.p7s): application/pkcs7-signature, 3802 bytes
hello experts, sorry for  my  offtopic  post
due  to the massive  influence from tycoon firms,
apple for  example during  the miss use of vlanhacks
and the ongoing  software patents disscussion
in europe and the pressure from the
http://www.mpaa.org/ on bittorrent users
i think there is a strong need for  Opencuseeme
a free peer2peer multiconferencing tool.
please  join

regards
www.cuseeme.de

(Continue reading)

Pyda Srisuresh | 4 Jun 19:33 2005
Picon

RE: Re: draft-ietf-behave-nat-udp-01, REQ-7


--- "Peterson, Jon" <jon.peterson <at> neustar.biz> wrote:

> 
> > One more reason, why I believe, we need to treat behave-gen and behave-udp
> as
> > two different drafts with different scopes and NOT combine them into one
> within
> > the UDP draft. Any comments?
>  
> I do have one further comment on this. It has become increasingly clear to me
> that treating these as separate drafts, with separate authors and terminology
> and ideas, is unlikely to be a path towards consensus. At best, I think it
> would sweep certain differences under the rug. I think it is preferable, and
> possible, to come to WG consensus about those differences. That should be
> done in the context of a single document.
> 
[suresh] It is interesting that you come to a different conclusion than I did.
I agree there shoudl be consensus on the terminology used across the drafts.
But, I dont see why there cannot be seperate drafts with seperate authors,
using the same terminology. What are the differences you think will be swept
under the carpet? 

FWIW, Bi-directional NATs effect the TCP apps just as they do the UDP apps. The
Bindings (Address and/or Port Bindings) are bi-directional in a Bi-Directional
NAT. As a result, Bi-Directional NAT is P2P friendly for both TCP and UDP apps.
So, going by your argument, why continue with a seperate draft for TCP? Why not
combine all three drafts (behave-gen, behave-udp & behave-tcp) into one? 

While on the subject, let me also point out that a NAT device may not be a pure
(Continue reading)


Gmane