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

From: "Kaushik Biswas (kbiswas)" <[email-masked]>
Date: Thu, 26 Jan 2006 14:34:16 -0800 (PST)

My suggestion would be include this along with "Port overloading"
discussion of Section 4.2.1. Yes this is a "bad NAT" no doubt.

Thanks,
Kaushik 

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Francois Audet
> Sent: Thursday, January 26, 2006 8:34 AM
> To: Karlheinz Wurm
> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Ietf-behave] missing defintion in 
> draft-ietf-behave-nat-udp-04
> 
> 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.
> > 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Jan 2006 10:05:26 -0800 (PST)

Thanks, we will make that editorial correction in Author's 48 hours.

> Sent: Friday, January 27, 2006 00:38
> Cc: Kaushik Biswas (kbiswas); ietf-behave@xxxxxxxxxxxxxxxxxxx
> btw., there is also a typo in Address and Port Dependent Mapping.
> 
> its written
> 
> ...(X:x) to the same external and port while ...
> 
> I am not native English speaker but i thought there is a "IP" 
> missing like
> 
> ...(X:x) to the same external IP and port while ...
> 
> Thanks,
> 
> Karlheinz
> 
> 
> Francois Audet wrote:
> > Guys,
> > 
> > The document is finished. In is awaiting publication.
> > 
> > If there is ever a revision to it, we can look for minor
> > clarifications like this to be added, but in the meanwhile, it
> > will stay as is...
> > 
> >> From: Kaushik Biswas (kbiswas) [mailto:kbiswas@xxxxxxxxx]
> >> Sent: Thursday, January 26, 2006 14:34
> >> To: Audet, Francois [SC100:9T51:EXCH]; Karlheinz Wurm
> >> My suggestion would be include this along with "Port
> >> overloading" discussion of Section 4.2.1. Yes this is a "bad 
> >> NAT" no doubt.
> >>
> >> Thanks,
> >> Kaushik
> >>
> >>> 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"...
> >>>
> 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: "Francois Audet" <[email-masked]>
Date: Tue, 31 Jan 2006 14:56:14 -0800 (PST)

My main worry about this is that it could open a can of worms...

If such a thing as "Port-only dependent mapping" is described, then
we may need to describe a "Port-only dependent filtering".

This means non-trivial changes to the document, which is awfuly late...

> Sent: Tuesday, January 31, 2006 03:20
> Did not check. Do you need it?
> 
> -- 
> Karlheinz Wurm,
> Skype Technologies S.A.
> 
> callto://wurm
> +372 536 36 975
> 
> > What is the filtering behavior of these evil NATs?
> > 
> > 
> > 
> >> Sent: Monday, January 30, 2006 01:21
> >> 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?
> >>
> >>
> >>>> 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 
> >>>> 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 
> >> +372 536 36 975