Subject: RE: [Ietf-behave] missing defintion in draft-ietf-behave-nat-udp-04

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Jan 2006 08:34:21 -0800 (PST)

Hum, that would be very broken...

It continues to amaze me that every possible broken scenario 
theoretically possible seems to be implemented somewhere by
someone...

This is essentially covered by the "Address and Port dependent
mapping", but is a special case of where y1 and y2 are the same.

Do you agree, or do you think it justifies having a
special case? Either way, it is a "bad NAT"...

> -----Original Message-----
> From: Karlheinz Wurm [mailto:karlheinz.wurm@xxxxxxxxx] 
> Sent: Thursday, January 26, 2006 00:07
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Ietf-behave] missing defintion in 
> draft-ietf-behave-nat-udp-04
> 
> 
> Francois Audet wrote:
> > You mean when Y1 and Y2 are different????
> > 
> 
> Y1 and Y2 are different but y1 and y2 are the same. Than the NAT will 
> bind it to the same external port.
> 
> e.g.
> 
> Local         RemoteAddress   External NAT address
> X:x           Y1:1925         X1':33394
> X:x           Y2:1925         X1':33394
> X:x           Y3:34575        X1':32781
> X:x           Y4:5986         X1':33625
> 
> And the worse is that the external port binding is completely random.
> 
> > Have you seen a NAT that actually does this?
> > 
> 
> Yes, i am just looking in one of this router. That's why i am missing 
> that definition. I don't want to name the model since we are 
> in business 
> relation with them but it is the latest model of one of the 
> very biggest 
> router vendors and widely distributed.
> 
> 
> >> -----Original Message-----
> >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> >> Karlheinz Wurm
> >> Sent: Wednesday, January 25, 2006 08:04
> >> To: ietf-behave@xxxxxxxxxxxxxxxxxxx
> >> Subject: [Ietf-behave] missing defintion in 
> >> draft-ietf-behave-nat-udp-04
> >>
> >>
> >> Hi everyone,
> >>
> >> Since I recently got confronted with the following behavior,
> >> i think one 
> >> definition is missing at point 4.1 ...  The following address 
> >> and port 
> >> mapping behavior are defined: ...
> >>
> >>
> >> I would call it a Port Dependent Mapping which means:
> >>
> >>     +------+                 +------+  x
> >>     |  Y1  |                 |  Y2  |  t
> >>     +--+---+                 +---+--+  e
> >>        | Y1:y1            Y2:y2  |     r
> >>        +----------+   +----------+     n
> >>                   |   |                a
> >>           X1':x1' |   | X2':x2'        l
> >>                +--+---+-+
> >>     ...........|   NAT  |...............
> >>                +--+---+-+              I
> >>                   |   |                n
> >>               X:x |   | X:x            t
> >>                  ++---++               e
> >>                  |  X  |               r
> >>                  +-----+               n
> >>                                        a
> >>
> >>        Port Dependent Mapping:
> >>           The NAT reuses the port mapping for subsequent 
> packets sent
> >>           from the same internal IP address and port (X:x) 
> to the same
> >>           external Port address, regardless of the external IP.
> >>           Specifically, X1':x1' equals X2':x2' if, and only
> >> if, y2 equals
> >>           y1.
> >>
> >>
> >> Kind regards,
> >>
> >> --
> >> Karlheinz Wurm,
> >> Skype Technologies S.A.
> >>
> >> callto://wurm
> >> +372 536 48 166
> >>
> >> Get Skype from http://www.skype.net
> >> We're hiring http://www.skype.net/company/jobs
> >> --
> >> This electronic transmission and any attached files are
> >> solely for the intended recipient and may contain information 
> >> that is privileged, confidential or otherwise protected from 
> >> disclosure. Any review, retransmission, dissemination or 
> >> other use, including taking any action concerning this 
> >> information by anyone other than the intended recipient, is 
> >> prohibited. If you are not the intended recipient or have 
> >> received this communication in error, please immediately 
> >> notify the sender and destroy this communication.
> >>
> 
> -- 
> Karlheinz Wurm,
> Skype Technologies S.A.
> 
> callto://wurm
> +372 536 48 166
> 
> Get Skype from http://www.skype.net
> We're hiring http://www.skype.net/company/jobs
> --
> This electronic transmission and any attached files are solely for the
> intended recipient and may contain information that is privileged,
> confidential or otherwise protected from disclosure. Any review,
> retransmission, dissemination or other use, including taking any
> action concerning this information by anyone other than the intended
> recipient, is prohibited. If you are not the intended recipient or
> have received this communication in error, please immediately notify
> the sender and destroy this communication.
>

---

From: Karlheinz Wurm <[email-masked]>
Date: Mon, 30 Jan 2006 01:21:03 -0800 (PST)

Francois Audet wrote:

This is essentially covered by the "Address and Port dependent
mapping", but is a special case of where y1 and y2 are the same.
Do you agree, or do you think it justifies having a
special case? 
I still think that this special case should be documented since all 
other cases are defined. In addition, it would be easier to 
explain/refer router vendors why it is a bad NAT.

Additional question: What is the roadmap to build the RFC out of this paper?

Either way, it is a "bad NAT"...

-----Original Message-----
From: Karlheinz Wurm [mailto:karlheinz.wurm@xxxxxxxxx] 
Sent: Thursday, January 26, 2006 00:07
To: Audet, Francois [SC100:9T51:EXCH]
Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Ietf-behave] missing defintion in 

Francois Audet wrote:

e.g.

-----Original Message-----

Hi everyone,

    +------+                 +------+  x
    |  Y1  |                 |  Y2  |  t
    +--+---+                 +---+--+  e
       | Y1:y1            Y2:y2  |     r

+372 536 36 975
begin:vcard
fn:Karlheinz Wurm
n:Wurm;Karlheinz
email;internet:karlheinz.wurm@xxxxxxxxx
tel;work:+1 (415) 508-3653
tel;cell:+372 536 369 75
x-mozilla-html:FALSE
version:2.1
end:vcard

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 1 Feb 2006 20:16:34 -0800 (PST)

> Additional question: What is the roadmap to build the RFC out of this paper?

The abridged version is ... We have sent it to the IESG for review. They
look at it, sometime they ask for changes. Then they send it to the RFC
Editor and it becomes an RFC.