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

From: "Christian Huitema" <[email-masked]>
Date: Tue, 17 May 2005 09:59:49 -0700 (PDT)

> 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

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 17 May 2005 11:50:07 -0700 (PDT)

> reasonable degree of protection.

Yes, I'm in 100% agreement with you.

---

From: Saikat Guha <[email-masked]>
Date: Tue, 17 May 2005 15:15:39 -0700 (PDT)

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

-- 
Saikat
Attachment:
signature.asc