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

From: [email-masked]
Date: Mon, 11 Jul 2011 12:08:37 -0700

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 Carrier Grade NAT (CGN)
	Author(s)       : Simon Perreault
                          Ikuhei Yamagata
                          Shin Miyakawa
                          Akira Nakagawa
                          Hiroyuki Ashida
	Filename        : draft-ietf-behave-lsn-requirements-02.txt
	Pages           : 16
	Date            : 2011-07-11

   This document defines common requirements for Carrier-Grade NAT
   (CGN).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-02.txt

---

From: Simon Perreault <[email-masked]>
Date: Mon, 11 Jul 2011 15:11:28 -0400

> 	Filename        : draft-ietf-behave-lsn-requirements-02.txt

This revision introduces many important changes. As far as I know it addresses
every issue that was raised.

Here's the change log:

   o  CGNs MUST support at least TCP, UDP, and ICMP.

   o  Add requirement from [I-D.ietf-intarea-ipv4-id-update].

   o  Add informative reference to
      [I-D.ietf-intarea-shared-addressing-issues].

   o  Add requirement (SHOULD level) for a port forwarding protocol.

   o  Allow any pooling behavior on a per-application protocol basis.

   o  Adjust wording for external port allocation rate limiting.

   o  Add requirement for RFC4008 support (SHOULD level).

   o  Adjust wording for swapping address pools when rebooting.

   o  Add DSCP requirement (stolen from draft-jennings-behave-nat6).

   o  Add informative reference to
      draft-boucadair-intarea-nat-reveal-analysis.

   o  Add requirement for hold-down pool.

   o  Change definition of CGN.

   o  Avoid usage of "device" loaded word throughout the document.

   o  Add requirement about resource exhaustion.

   o  Change title.

   o  Describe additional CGN topology where there is no NAT444.

   o  Better justification for "Paired" pool behavior.

   o  Make it clear that rate limiting allocation is for preserving CPU
      resources

   o  Generalize the requirement for limiting the number of TCP sessions
      per mapping so that it applies to all memory-consuming state
      elements.

   o  Change CPE to subscriber where it applies throughout the text.

   o  Better terminology for bulk port allocation mechanisms.

   o  Explain how external address pairing works with DS-Lite.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 12 Jul 2011 10:43:47 -0400

Hello Simon,

Thanks for the updated draft. It shows a lot of good progress.

I'm going through it and have a few questions regarding REQ-7 and REQ-8.

Given there was discussion on the list about these requirements and no
definite consensus on the wording or purpose (
http://www.ietf.org/mail-archive/web/behave/current/msg09433.html) I was
surprised to see them in the new version.

It seems we are trying to solve the address change problem in another
fashion (..."This is to prevent users from receiving unwanted traffic").

As discussed in http://www.ietf.org/id/draft-ietf-pcp-base-13.txt, section
8.7, address change already happens today and traffic is directed to another
CPE with or w/o CGN.

"  REQ-7:  When a CGN loses state (due to a crash, reboot, failover to a
           cold standby, etc.), it MUST NOT reuse the same external IP
           addresses for new dynamic mappings for at least 120 seconds.

   Justification:  This is necessary in order to prevent collisions
      between old and new mappings and sessions.  It ensures that all
      established sessions are broken instead of redirected to a
      different peer.  The previous address pool MAY of course be reused
      after a second loss of state."

If the premise is that when a CGN reboots it looses state, can you elaborate
on the use cases on how packets will be directed to a different peer in case
a CGN reboots and reuses the same NAT pool in less than 120 seconds?

"   REQ-8:  Once an external port is deallocated, it SHOULD NOT be
           reallocated to a new mapping until at least 120 seconds have
           passed.  The length of time and the maximum number of ports
           in this state SHOULD be configurable by the CGN
           administrator.

   Justification:  This is to prevent users from receiving unwanted
      traffic.  It also helps prevent against clock skew when mappings
      are logged."

Another question, when you say " The length of time and the maximum number
of ports in this state SHOULD be configurable by the CGN administrator." do
you mean it can be configured to be less than 120 seconds

Or

It can configured but it needs to be more than 120 seconds.

Thanks,

Reinaldo

On 7/11/11 12:11 PM, "Simon Perreault" <[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.
>>

---

From: Simon Perreault <[email-masked]>
Date: Tue, 12 Jul 2011 11:18:50 -0400

> surprised to see them in the new version.

My task is to edit the draft to match the WG's consensus. I'm sorry my
evaluation of the consensus didn't match yours. As usual in the IETF, when
you're unhappy with the contents of a draft, please discuss. ;)

> 8.7, address change already happens today and traffic is directed to another

If I understand correctly, address change events with DHCP are dealt with by
having the DHCP server wait a while before reassigning the old address to a new
subscriber. This is very similar to what is currently in our draft. So I see
this as a sign we're going in the right direction.

(I don't understand your objection. I'm not even sure if you're objecting.)

> a CGN reboots and reuses the same NAT pool in less than 120 seconds?

Address 1.2.3.4 is assigned to subscriber A.
CGN reboots in 10 seconds.
CGN assigns 1.2.3.4 to subscriber B.
Subscriber B receives traffic intended for subscriber A.

(Is that really what you expected me to explain?)

> It can configured but it needs to be more than 120 seconds.

My understanding: The first SHOULD NOT still holds. So it SHOULD be fully
configurable, and an administrator SHOULD NOT set it lower than 120 seconds but
could do so by breaking the SHOULD NOT, which may be justified in some
controlled contexts (e.g. not on the public Internet).

Let me know if you can think of better wording.

Simon

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 12 Jul 2011 11:24:58 -0400

> (I don't understand your objection. I'm not even sure if you're objecting.)

I'm not there is such recommendation in RFC. Can we put a reference to it in
this draft?

> Subscriber B receives traffic intended for subscriber A.

External->internal traffic would be dropped by NAT since there is no mapping
for a specific session.

What would the use case where traffic would reach subscriber B?

> Let me know if you can think of better wording.

I would advocate it MAY be configured to be less than 120 seconds (even in
public Internet)

---

From: Simon Perreault <[email-masked]>
Date: Tue, 12 Jul 2011 11:47:01 -0400

> I'm not there is such recommendation in RFC. Can we put a reference to it in

I haven't found any, sorry.

> External->internal traffic would be dropped by NAT since there is no mapping

I don't understand. Let me add ports to make the mappings explicit:

Address+port 1.2.3.4:1234 is assigned to subscriber A.
CGN reboots in 10 seconds.
CGN assigns 1.2.3.4:1234 to subscriber B.
Subscriber B receives traffic intended for subscriber A.

Note that RFC 5382 does not require NATs to track TCP session numbers (and most
do not). It doesn't even require that TCP sessions be tracked at all (some NATs
don't track sessions).

> I would advocate it MAY be configured to be less than 120 seconds (even in

Please explain why. Also, would you be in favour of simply dropping that
requirement?

Simon

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 12 Jul 2011 13:18:38 -0400

> do not). It doesn't even require that TCP sessions be tracked at all (some

Stateful-NAT64 does require TCP session tracking.
http://tools.ietf.org/html/rfc6146, section 3.5.2.2.  State Machine for TCP
Processing in the NAT64.

And more related to NAPT44, if first packet of a TCP session is not-SYN I
posit that most CGNs in the market will not allow the session to be
established. It is just de facto behavior. Therefore I still question if
there is such a use case that justifies this requirement.

> Please explain why. Also, would you be in favour of simply dropping that

My explanation is that we have a requirement that:

1 - Tries to address a situation where use case is not clear or does not
affect most implementations. And By doing that, we get collateral damage in
the form of 2 below.

2 - Create a burden for CGN deployment that certain ISPs might not care. We
are making a choice of behalf of everybody else instead of giving ISP the
choice. The quick numbers are crunched are in this message.

http://www.ietf.org/mail-archive/web/behave/current/msg09433.html

If and ISP A wants to put this requirement on their RFP, that is fine, but
as standards go, we should give ISP B-Z a choice.

Thanks,

Reinaldo

---

From: Simon Perreault <[email-masked]>
Date: Tue, 12 Jul 2011 14:46:30 -0400

> there is such a use case that justifies this requirement.

But the first packet *is* a SYN! After the CGN reboots, 1.2.3.4:1234 gets
assigned to B precisely because B initiated a new session with a SYN. Since the
CGN is EIM, the remote peer doesn't matter. The old peer can send data through
the new session if it uses the same external address+port.

> affect most implementations. And By doing that, we get collateral damage in

We first need to resolve that.

> http://www.ietf.org/mail-archive/web/behave/current/msg09433.html

That number crunching was addressed with the -02 revision. Instead of having two
separate pools, we now only require that address+ports that were in use do not
get reused within 120 seconds. This is very different.

Simon

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 12 Jul 2011 17:45:09 -0400

On 7/12/11 11:46 AM, "Simon Perreault" <[email-masked]> wrote:

> assigned to B precisely because B initiated a new session with a SYN.

_and_ the reply needs to be a SYN-ACK, which it will not. Otherwise it is a
perfectly good session to a remote server.

> Since 
> the

No, it can not. Inbound sessions through EIF still need to start with a SYN.
Just because there is external public IP:port it does not mean that any
connection sequence is allowed.

A (private)-->SYN-->B (establishes EIF mapping)
A (private)<---TCP ACK<---C (packet will be dropped)
A (private)<---TCP SYN<---D (okay)

Moreover, as we discussed on PCP, not all NATs are EIF capable and not all
NATs enable EIF for all sessions. Therefore the requirement is overreaching
its usefulness. 

Again, I still do not see a use where this can happen. And even if there is,
based on this discussion it seems we have a misplaced requirement for a
situation that is the exception.

> get reused within 120 seconds. This is very different.

Not quite. The effect is the same. In a CGN capable of, say, 250k
sessions/sec, in 120 seconds, you need to have 120*250K extra ports. That is
468 public IP addresses.

In summary, we are basically saying that even if a CGN can failover under
120 seconds, there is no point since the ISP can not reuse the ports anyway.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 13 Jul 2011 08:22:14 -0400

> A (private)<---TCP SYN<---D (okay)

Is there any RFC that says that the packet must be dropped? As far as I
know, it depends on the NAT implementation. Either dropping or
forwarding is fine, AFAIK.

I know that at least one CGN vendor will forward the packet (based on a
written description. I haven't tested this yet.)

If you're right and this is specified somewhere in an RFC, then I agree
we could drop this requirement. Otherwise, we could still generalize the
requirement, e.g. "a CGN MUST ensure that no traffic intended for one
user gets forwarded to another user", and then list the two methods we
know that work, i.e. tracking TCP sessions or waiting 120 seconds before
reassigning the port.

> sessions/sec, in 120 seconds, you need to have 120*250K extra ports. That is

I don't understand your math. The CGN only needs to put the port in the
hold down pool when it gets reassigned to a different subscriber. The
hold down pool is bypassed when the port gets reassigned to a different
session but to the *same* subscriber.

> 120 seconds, there is no point since the ISP can not reuse the ports anyway.

We need to be careful here. By failover, you mean stateless failover
(i.e. losing state), right? Because the case of stateful failover, this
requirement does not apply. It's only when you lose state that you need
to put the ports that were in use when state was lost in the hold down pool.

Simon

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 13 Jul 2011 09:11:59 -0400

Hi Simon,

Comments inline...

> forwarding is fine, AFAIK.

Stateful NAT64 says TCP sessions must start with SYN. Therefore I assume it
applies for all sessions, otherwise something else would have been
specified.

> written description. I haven't tested this yet.)

It is possible but I believe it to be a security hole in general, not
necessarily tied to reboot since an EIF mapping can be easily exploited.

> we could drop this requirement.

I do not believe the requirement should be dropped. I just believe it is
misplaced in a sense that we are using the '120 seconds' as a jack of all
trades. If the problem we are trying to solve is unwanted traffic we can be
more fine grained on the solution (see below).

> Otherwise, we could still generalize the

If the problem we are trying to solve is unwanted traffic we can be more
fine grained on the wording. Suggestion below.

1 - There is no issue with APF (address and port dependent filtering)
whether the user tracks TCP sessions or not. Therefore the requirement
should not apply to such mappings.

2 - In the case of EIF mappings, if the CGN tracks TCP sessions there is no
need to wait 120 seconds.

3 - In the case of EIF mappings, if the CGN does not track TCP sessions, it
SHOULD wait 120 seconds before assigning the port to a different
subscribers.

> hold down pool when it gets reassigned to a different subscriber.

How will you know that after a reboot when all state is lost?

> The
> (i.e. losing state), right?

Right. The requirement seems to be hampering innovation by establishing a
lower threshold for failover

> Because the case of stateful failover, this

---

From: Simon Perreault <[email-masked]>
Date: Wed, 13 Jul 2011 09:48:28 -0400

> applies for all sessions, otherwise something else would have been

Well... you know where this is going... NAT64 is out of scope. This
draft is only concerned with NAT44.

> necessarily tied to reboot since an EIF mapping can be easily exploited.

Right. And many others go further and consider NATs that don't track TCP
sequence numbers to be useless pieces of crap (which is why
security-conscious OpenBSD designed pf with TCP sequence number
tracking). So the security argument is relative to what one considers
"secure enough".

> should not apply to such mappings.

Right, but:

   REQ-6:  It is RECOMMENDED that a CGN have an "Endpoint-Independent
           Filtering" behavior.

> need to wait 120 seconds.

Agreed.

> SHOULD wait 120 seconds before assigning the port to a different

Agreed.

> How will you know that after a reboot when all state is lost?

Ah, you're right. Thanks.

I think we can reach a conclusion. If we generalize the requirement so
that NATs that do TCP session tracking don't need a hold down pool,
would that fully address your concern?

Simon

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 13 Jul 2011 10:09:49 -0400

> draft is only concerned with NAT44.

Oh well, but I hoped it would be related to CGN (address sharing) in
general, otherwise we will have 3x (or more the work) when writing similar
drafts for NAT64, DS-Lite, and others that fall into the 'address sharing'
category.

>    REQ-6:  It is RECOMMENDED that a CGN have an "Endpoint-Independent

Yes, but other types of filtering are perfectly fine depending on security
and other inputs.

   REQ-8:  If application transparency is most important, it is
      RECOMMENDED that a NAT have an "Endpoint-Independent Filtering"
      behavior.  If a more stringent filtering behavior is most
      important, it is RECOMMENDED that a NAT have an "Address-Dependent
      Filtering" behavior.

      a) The filtering behavior MAY be an option configurable by the
         administrator of the NAT.

> would that fully address your concern?

Yes, but we should also mention that the requirement does not apply to
Address dependent filtering and Address and port dependent filtering.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 13 Jul 2011 10:15:49 -0400

> Address dependent filtering and Address and port dependent filtering.

Will do.

Thanks for the discussion!

Simon

---

From: Dave Thaler <[email-masked]>
Date: Fri, 22 Jul 2011 01:20:09 +0000

I read through the latest version and I think this is very close now.

Here's my feedback on -02:

> REQ-7:  When a CGN loses state (due to a crash, reboot, failover to a

>         addresses for new dynamic mappings for at least 120 seconds.

          ^^^^^^^^^

I believe REQ-7 should probably say "ports" (or "address/port pairs")

not "addresses".   As long as there's no collisions between old and new

addr/port pairs, it doesn't matter whether it uses different ports for

the same address or a different address.

> REQ-9:  A CGN MUST handle the IPv4 ID field of translated packets as

>         described in [I-D.ietf-intarea-ipv4-id-update] section 9.

Is this really specific to a CGN?  Or would it apply to *all* NATs?

The justification section implies that I-D.ietf-intarea-ipv4-id-update

section 9 already provides a justification for this being CGN specific.

It doesn't, as far as I can tell, so additional elaboration is needed

if this (or at least raising it to a MUST) is CGN specific.

> REQ-10:  A CGN SHOULD support a port forwarding protocol such as the

>          Port Control Protocol [I-D.ietf-pcp-base].

Wording is ambiguous.  What does "support" mean?  For example, if it

can be a PCP client but not a PCP server, does that pass? (it shouldn't)

Furthermore, the justification provided is insufficient in my opinion,

given that a specific protocol is not even recommended.  For example,

would it be ok if someone implemented the SHOULD with some protocol

no CPE supported, or if every CGN vendor had a proprietary protocol?

Again my point is that it's ambiguous.  My personal preference would be

to explicitly say that PCP server support is a SHOULD, and move pcp-base

to a normative reference.

>   REQ-13:  When a CGN is unable to create a mapping due to resource

>            contraints or administrative restrictions (i.e. quotas)...

             ^^^^^^^^^^

Typo: constraints

[...]

>            D.  and it MUST NOT delete existing mappings in order to

>                "make room" for the new one.

I don't understand why the above is a MUST NOT (especially if the old

mapping has been idle for a long time).  Either provide justification

or relax this.

Section 4:

>   o  destination address (but see below)

>   o  destination port (but see below)

It's unclear whether this means a CGN MUST, SHOULD,

or MAY log dest addr/port.   This document should be

clear enough for someone to write a compliance test.

In fact this entire section has no normative

requirements language :(

My personal opinion is that logging support is a

SHOULD, but dest addr/port support is only a MAY.

But I'm open to other opinions.

Section 5:

> There is a range of things a CGN can do:

Suggest s/can/MAY/

(And as it says, it's not a complete list and

I can easily imagine other algorithms that would

be better in many/most cases.)

-Dave

> -----Original Message-----

> From: [email-masked] [mailto:[email-masked]] On Behalf

> Of Simon Perreault

> Sent: Monday, July 11, 2011 12:11 PM

> To: [email-masked]

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

> [email-masked]<mailto:[email-masked]> wrote, on 07/11/2011 03:08 PM:

> This revision introduces many important changes. As far as I know it

> addresses every issue that was raised.

> _______________________________________________

> Behave mailing list

> [email-masked]<mailto:[email-masked]>

> https://www.ietf.org/mailman/listinfo/behave

---

From: Simon Perreault <[email-masked]>
Date: Fri, 22 Jul 2011 10:13:22 -0400

Agreed.

> Is this really specific to a CGN?  Or would it apply to **all** NATs?

Thanks for pointing this out. As editor I was torn between recording WG
consensus and my own opinion.

In my opinion this requirement should be deleted.
I-D.ietf-intarea-ipv4-id-update as it stands already contains normative
text that applies to all NATs, so it definitely already includes CGNs.
So I don't think we need to say anything additional in this document.

> can be a PCP client but not a PCP server, does that pass? (it shouldn’t)

Agreed.

> to a normative reference.

I share your preference.

In other words: +1

> […]

In my understanding, the justification is because applications generally
handle connection establishment failure better than established
connection failure. I'm fine with relaxing this to a SHOULD NOT.

> In fact this entire section has no normative

My understanding is that the whole section is non-normative.

> But I'm open to other opinions.

I'll let the WG discuss that.

> be better in many/most cases.)

Right. Once again I understand this section to be non-normative. I'm
fine with transforming it into normative requirements, but there needs
to be WG discussion about what a CGN MAY/SHOULD/MUST do.

Simon

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 28 Jul 2011 08:15:42 +0200 (CEST)

>   o Better terminology for bulk port allocation mechanisms.

I really really like that "bulk port allocation" is included. I would like 
it to be a SHOULD requirement.

Having CGN handle tens of gigabit/s of normal Internet user traffic and 
trying to log 6 tuple (internal, external and destination ip/port) creates 
a huge amount of logging entries. In some markets we see existing or 
upcoming legal requirements to store logging data for years, so this 
creates a huge problem which as far as I can discern today, means the 
logging system actually becomes more expensive than the LSN device itself.

Having bulk port allocation reduces the amount of logging by many 
magnitues (if one only logs the port allocation block creation and 
teardown, and requires any tracking/abuse report to include source port).

I would also like to have included language that if I have 5000 users and 
1000 external IP addresses, these 5000 users should be spread out over the 
pool so that the median of users per external IP address is close to 5 in 
this case. That means that for legal tracking, the legal entity can be 
given a list of 5 users even if one cannot say exactly which of the 5 did 
something at a certain time.

I already know several vendors who have this feature in working code 
today, so having it described in a formal document would be beneficial to 
help bring more vendors to implement this behaviour.

-- 
Mikael Abrahamsson    email: [email-masked]