Subject: Re: [BEHAVE] Comments and question on scope of Re: I-D Action:draft-ietf-behave-lsn-requirements-00.txt

From: "Ikuhei.Yamagata" <[email-masked]>
Date: Thu, 04 Nov 2010 17:46:58 +0900

Hi, Reinaldo

Thank you for your comment and sorry for our is delay...

Comments inline...

On Wed, 20 Oct 2010 12:09:09 -0400
Reinaldo Penno <[email-masked]> wrote:

> Hello Dan,
> 
> Comments inline...
> 
> 
> On 10/20/10 8:57 AM, "Dan Wing" <[email-masked]> wrote:
> 
> >> -----Original Message-----
> >> From: Reinaldo Penno [mailto:[email-masked]]
> >> Sent: Wednesday, October 20, 2010 3:35 AM
> >> To: Ikuhei.Yamagata; [email-masked]; Dave Thaler
> >> Cc: [email-masked]; Dan Wing
> >> Subject: Comments and question on scope of Re: [BEHAVE] I-D
> >> Action:draft-ietf-behave-lsn-requirements-00.txt
> >> 
> >> Hello
> >> 
> >> I think this document is a good start but needs some work as WG
> >> document.
> >> 
> >> First and foremost a question to chairs/WG: does this document apply
> >> only to NAT44(4) or NAT64 and DS-Lite as well?
> > 
> > Anytime there is a "large" NAT.  So all of those you listed, and
> > probably other architectures as well.
> 
> Thanks for the clarification.
> 
> > 
> >> NAT64 and DS-Lite also use/are 'LSN' and if this is the case the
> >> document needs more text to cater to those scenarios.
> >> 
> >> Comments to this document.
> >> 
> >> 1 -
> >> 
> >> Some of the original CGN requirements document used to just copy &
> >> paste
> >> requirements from RFC4787, RFC5382 and RFC5508.
> >> 
> >> I'm glad to see most of that text was removed since it was repetitive
> >> but
> >> the draft still mentions that "However so, because those RFCs are
> >> mainly
> >> aimed at residential CPE
> >>    and any IPv4 address sharing schemes are a bit different from it, we
> >>    believe that requirements for LSN and other schemes should be
> >> defined
> >>    alternatively to those RFCs."
> >> 
> >> But I do not see any requirements that are alternative/opposed to the
> >> original RFCs. Only a few new things. Sections 4 and 5 seem to have
> >> nothing
> >> different from the original RFCs - or maybe it is my interpretation.
> >> 

Sections 3 and 4 have a few new things, but it maybe hard to find.

> >> Is it possible to flag more descriptively which requirements in the
> >> draft are alternative/opposed from RFC4787, RFC5382 and RFC5508?
> > 
> > I agree the document should be clearer when it is re-stating a
> > requirement or when it is changing an existing requirement.  I have
> > suggested changes to the document authors (as an individual) but
> > those suggestions have not been integrated.
OK. We try to write more clear about it.

> > 
> >> 2 -
> >> 
> >> The requirements for translation log differ across different countries,
> >> law
> >> enforcement and others. Therefore section 7.1 can not be applied to all
> >> LSNs. Certain ISPs are not so interested in destination IP address and
> >> port and can use port ranges for users (see below)
> > 
> > There are three documents (that I'm aware of) which discuss logging
> > to different degrees:
> > 
> >   draft-ietf-behave-lsn-requirements
> >   draft-ietf-intarea-shared-addressing-issues
> >   draft-durand-server-logging-recommendations
> > 
> > We should decide where that text needs to live, and what that text
> > needs to say.  
We think so, and our thought is similar to draft-ietf-intarea-shared-addressing-issues.
If servers log source port number like draft-durand-server-logging-recommendations, LSNs are not need to log destination address.

> > 
> > 
> >> 3 -
> >> 
> >> Section 7.2 text is somewhat confusing when states that
> >> 
> >> " Note that
> >>    this mechanism is possible only if the source port is known as well
> >>    as the source address, the destination address and the destination
> >>    port."
> >> 
> >> Maybe I'm missing something but how the destination address will be
> >> known in
> >> advance? There are millions websites in the world and you can not know
> >> which
> >> one the subscriber will access at any given point in time.
> >> 
> >> My suggestion is to reword as
> >> 
> >> " Note that
> >>    this mechanism is possible only if logging the destination IP and
> >> port by
> >> the LSN is not necessary"
> >> 
> >> See the discussion in
> >> http://tools.ietf.org/html/draft-tsou-behave-natx4-log-reduction-02
> >> 
This means "If servers log not only source address but also source port, 
this mechanism is possible".

This means servers are need to know(log) source port, source address, destination address(server's IP address) and 
destination port(e.x http is tcp 80) if LSN use this mechanism.

> >> 4- -
> >> 
> >> I could not follow this requirement. Could you elaborate?
> >> 
> >> "     b) A LSN MAY reuse LSN external port while the port is allocated
> >>       for no session originated by any CPE."
> >> 
Yes, we write on purpose. But it may be incomprehensible...

This example...
userA gets LSN's port range in advance.(IPaddress:100.0.0.1 port number:1024-2048)
userB trys to connect with same LSN, but there is not enough address:port.
In this case, userB can use ports which gotten and not used by a userA.

But, I am afraid of misunderstanding, so we think to change like this.
b) A LSN MUST NOT use LSN external port allocated and used by any CPE.

> >> 5 -
> >> 
> >> Why the two requirements below are a 'SHOULD'?
> >> 
> >> "      c) A LSN SHOULD limit the number of the LSN external ports of
> >> TCP
> >>       per CPE.
> >> 
> >>       e) A LSN SHOULD limit the number of the new sessions of TCP per
> >>       time unit and per CPE."
> >> 
> >> In some ISPs the ratio of available ports to subscriber (compression)
> >> is
> >> very low and those mechanisms are not needed at all.
> > 
> > Disagree.  Without such a limit, a malfunctioning host or a host
> > doing port scanning could consume all 64K ports, causing a DoS for
> > other users behind that same NAT, without consuming much bandwidth
> > at all.
> 
> Exactly, some people agree others do not. This is a deployment decision. We
> provide a knob and let ISPs decide.
> 
> > 
> >> This varies
> >> considerably across deployments.
> >> 
> >> I suggest to reword this as ..."the LSN MAY allow the number of
> >> external TCP
> >> ports and sessions per second per subscriber to be configured"
> > 
> > I believe the requirement is that a large scale NAT provide a 'knob'
> > to allow the LSN operator to set the value.
> 
> Yes. 
We think so, too.
And we think many ISP use port limitation function.
So, we think "SHOULD" is comfortable.

> 
> > 
> > 
> >> 6 -
> >> 
> >> The text below seems somewhat ambiguous
> >> 
> >> "  Justification: Some specific applications don't work well due to
> >>    limitation of number of number of ports by LSN, therefore other
> >>    applications might be affected in the same CPE."
> >> 
> >> All application will be affected by limiting the number of ports if all
> >> ports were consumed. It is just a function of time and how many ports
> >> have
> >> been consumed not the application per se.
> >> 
Yes.
Some application may deadlock because application cannot connect DNS server (for limiting connection).
We are afraid of this, so we think this function.
But we don't know there is applications like this, so we write "MAY".

> >> 7 -
> >> 
> >> In section 10 I'm not sure what is the requirement exactly. Can you
> >> give an
> >> example on how preventing spoofing can be achieved in NAT444
> >> deployments as
> >> opposed to, say, DS-Lite. A subscriber can spoof the 3-tuple unless
> >> that is
> >> prevented on the CPE itself.
> > 
> > In NAT444, ingress filtering works just like it does today:  the
> > source address of traffic from the subscriber can be filtered to
> > only be the IP address assigned by DHCP (or PPP).
> 
> 
> I think there is a disconnect. If the LSN is deep into the network, how it
> will perform ingress filtering for DHCP subs? How will it know that packets
> from source IP 10.0.0.2 are coming from CPE B instead of CPE C, or D?
> 
> PPP is okay, I understand this scenario.
> Unless each subscriber is routed to a different interface/VLAN, also
> understand this scenario.
> 
> 
> > 
> >> Or maybe it is not a spoof and just that IP address was reassigned and
> >> still
> >> many TCP sessions lingering on the LSN preventing new subscriber from
> >> establishing sessions.
> > 
> > IPv4 address re-assignment happens today, on today's Internet, with
> > some ISPs.  ISPs do that to thwart subscribers running servers.  Those
> > same ISPs will have fewer reasons to re-assign the subscriber IP address
> > when the subscriber is behind a LSN.
> > 
> > -d
> > 
> > 
> >> Thanks,
> >> 
> >> Reinaldo
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> On 10/19/10 6:18 PM, "Ikuhei.Yamagata" <[email-masked]> wrote:
> >> 
> >>> Dear all,
> >>> 
> >>> We posted new behave WG, draft-ietf-behave-lsn-requirements.
> >>> This draft changed from draft-nishitani-cgn, and some requirements
> >> changes.
> >>> 
> >>> Comments most welcomed!
> >>> 
> >>> Best wishes,
> >>> ikuhei
> >>> 
> >>> On Mon, 18 Oct 2010 02:30:09 -0700 (PDT)
> >>> [email-masked] wrote:
> >>> 
> >>>> A New Internet-Draft is available from the on-line Internet-Drafts
> >>>> directories.
> >>>> This draft is a work item of the Behavior Engineering for Hindrance
> >> Avoidance
> >>>> Working Group of the IETF.
> >>>> 
> >>>> 
> >>>> Title           : Common requirements for IP address sharing schemes
> >>>> Author(s)       : I. Yamagata, et al.
> >>>> Filename        : draft-ietf-behave-lsn-requirements-00.txt
> >>>> Pages           : 13
> >>>> Date            : 2010-10-18
> >>>> 
> >>>> This document defines common requirements of multiple types of Large
> >>>> Scale Network Address Translation (NAT) that handles Unicast UDP,
> >> TCP
> >>>> and ICMP.
> >>>> 
> >>>> A URL for this Internet-Draft is:
> >>>> http://www.ietf.org/internet-drafts/draft-ietf-behave-lsn-
> >> requirements-00.txt
> >>>> 
> >>>> Internet-Drafts are also available by anonymous FTP at:
> >>>> ftp://ftp.ietf.org/internet-drafts/
> >>>> 
> >>>> Below is the data which will enable a MIME compliant mail reader
> >>>> implementation to automatically retrieve the ASCII version of the
> >>>> Internet-Draft.
> >>> 
> >>> ----------------------------------------------
> >>> Ikuhei Yamagata
> >>> Innovative IP Architecture Center
> >>> NTT Communications Corporation
> >>> [email-masked]
> >>> phone:81-3-6733-8671(main)
> >>>             50-3812-4704(direct)
> >>> ----------------------------------------------
> >>> 
> >>> _______________________________________________
> >>> Behave mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/behave
> > 
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

----------------------------------------------
Ikuhei Yamagata
Innovative IP Architecture Center
NTT Communications Corporation
[email-masked]
phone:81-3-6733-8671(main)
            50-3812-4704(direct)
----------------------------------------------