Subject: [BEHAVE] I-D Action:draft-ietf-behave-lsn-requirements-00.txt

From: [email-masked]
Date: Mon, 18 Oct 2010 02:30:09 -0700 (PDT)

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.

---

From: "Ikuhei.Yamagata" <[email-masked]>
Date: Wed, 20 Oct 2010 10:18:37 +0900

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

> implementation to automatically retrieve the ASCII version of the

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

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 20 Oct 2010 06:35:19 -0400

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?

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.

Is it possible to flag more descriptively which requirements in the draft
are alternative/opposed from RFC4787, RFC5382 and RFC5508?

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)

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

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

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

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.

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.

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.

Thanks,

Reinaldo

On 10/19/10 6:18 PM, "Ikuhei.Yamagata" <[email-masked]> wrote:

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Oct 2010 08:57:54 -0700

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

> NAT64 and DS-Lite also use/are 'LSN' and if this is the case the
> document needs more text to cater to those scenarios.
> 
> 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.

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

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

> This varies

I believe the requirement is that a large scale NAT provide a 'knob'
to allow the LSN operator to set the value.  

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

> many TCP sessions lingering on the LSN preventing new subscriber from

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

> >> This draft is a work item of the Behavior Engineering for Hindrance
> Avoidance
> >> Working Group of the IETF.
> >>
> >>

---

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

Hello Dan,

Comments inline...

> probably other architectures as well.

Thanks for the clarification.

> other users behind that same NAT, without consuming much bandwidth

Exactly, some people agree others do not. This is a deployment decision. We
provide a knob and let ISPs decide.

> to allow the LSN operator to set the value.

Yes. 

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

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Oct 2010 09:31:59 -0700

> >> In some ISPs the ratio of available ports to subscriber
> (compression)
> >> is
> Exactly, some people agree others do not. This is a deployment
> decision. We provide a knob and let ISPs decide.

Would "MUST provide the ability to restrict # of ports allocated to an 
interior host or subscriber, to allow operator to prevent a single
host or subscriber from consuming all ports" be reasonable wording?

...
> will perform ingress filtering for DHCP subs?

It can't.  The filtering has to be configured on the network equipment
close enough to the subscriber to effectively filter.  That is similar,
if not identical, to how ingress filtering works today; if ingress
filtering is done too far from the subscriber, it allows a subscriber
to spoof traffic within the ISP's network (interior to wherever the
filtering is done), such as towards their neighbor down the street.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 20 Oct 2010 12:53:15 -0400

Yes.

> filtering is done), such as towards their neighbor down the street.

Okay, we seem to agree, but then how can this be a general LSN requirement?
It can only be a requirement if the LSN is close to the subscribers. If we
can word like that I'm okay.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Oct 2010 10:35:46 -0700

> Sent: Wednesday, October 20, 2010 9:53 AM
> To: Dan Wing; 'Ikuhei.Yamagata'; [email-masked]; 'Dave Thaler'
> Cc: [email-masked]
> Subject: Re: Comments and question on scope of Re: [BEHAVE] I-D
> >> I think there is a disconnect. If the LSN is deep into the network,
> how
> >> it

If the LSN is not directly connected to subscribers (i.e., the LSN is not
draft-miles-behave-l2nat, DS-Lite tunnel, draft-arkko-dual-stack-extra-lite,
etc.), I agree with what you're saying.  I believe we can craft wording
around the case where the CGN is directly connected to subscribers and,
where the CGN is not directly connected to subscribers it is a requirement
of the network to do ingress filtering.

-d