Subject: [apps-discuss] Apps Area Review of draft-ietf-behave-lsn-requirements-05

From: Eliot Lear <[email-masked]>
Date: Tue, 13 Dec 2011 19:14:30 +0100

Greetings draft authors!

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
 http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-behave-lsn-requirements-05
Title: Common requirements for Carrier Grade NATs (CGNs)
Reviewer: Eliot Lear
Review Date: 13 Dec. 2011

This proposed BCP specifies requirements for Carrier Grade NATs.  In my
opinion, there are several major issues and several questions should be
answered before this draft is progressed.

*Major issues*

The following text needs substantial work.

>    Readers should be aware of potential issues that may arise when
>    sharing a public address between many subscribers.  See [RFC6269 <http://tools.ietf.org/html/rfc6269>] for
>    details.
As such, the caution listed above seems extremely weak.  There is *no
way* to safeguard applications 100% against the problems of CGNs, just
as there was no way to safeguard applications from NATs.  CGNs introduce
a new level of problems, which you reference, but this must be said.  I
am not asking for you to go into a whole rant on CGNs, but "issues"
reminds me of "obviously, there's been a major malfunction".

  * Req1: Whither SCTP?  At the very least someone should say something
    about why SCTP is NOT on the list.  Moreover, your logic in this
    requirement to me doesn't hold.  There is a substantial difference
    between a NAT within an administrative domain that can be managed by
    the subscriber, and one that realistically cannot be.  Therefore,
    the requirements upon CGNs should be *stronger*.  Of course this
    should be balanced by other considerations, such as keeping the
    Internet growing, but the logic needs to be exposed.  For instance,
    it may not be possible to safeguard certain IPSEC deployments.
  * Req10: §14.1.1 of draft-ietf-pcp-base-16 states that failure to
    segment of traffic opens attacks.  Why was a requirement not added
    to address this?
  * Req13: Question; if destination addresses and ports are not logged,
    is there sufficient information to determine a UNIQUE mapping
    necessary for LI purposes?  Put another way, is the mapping a
    3-tuple or a 5-tuple?
  * This requirements document should be reviewed by game developers to
    get their PoV.  As I understand it, they don't do pcp, but more
    uPnP, ice & stun. Perhaps that's just a timing thing.

*Minor issues*

  * I understand that traditional telcos might not be the only ones to
    offer CGN, the definition of a CGN seems strained, particulary as
    when relates to "administrative entity".  This may be in part due to
    the expansion of scope of what is trying to be solved.  I have no
    great suggestion for you here.

*Nits*

  * Yes, there is a terminology section, but NAT un-NATing, and ISPs are
    not properly defined in their first use in the Introduction.
  * In Figure 1 it may be useful to show IP addresses.

*Very very very nitty (can largely be ignored)*

  * Something odd going on with your reference to RFC5382 on
    tools.ietf.org– no link.  Check source and maybe check with the IETF
    tools people.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 14 Dec 2011 10:22:07 -0500

Eliot,

Thanks for your review.

As you'll see below, I did not agree with many of your suggestions. It is 
unusual, my style is not to push back a lot. I'm sorry about that.

On 2011-12-13 13:14, Eliot Lear wrote:
> As such, the caution listed above seems extremely weak.  There is *no way* to
> safeguard applications 100% against the problems of CGNs, just as there was no
> way to safeguard applications from NATs.  CGNs introduce a new level of problems,
> which you reference, but this must be said.  I am not asking for you to go into a
> whole rant on CGNs, but "issues" reminds me of "obviously, there's been a major
> malfunction".

I'm sorry, I don't know how to translate that into text. RFC6269 appears clear to 
me. Do you have an example of text you would like to see?

>   * Req1: Whither SCTP?  At the very least someone should say something about why
>     SCTP is NOT on the list.

There are BEHAVE RFCs we can cite regarding NAT behaviour for TCP, UDP, and ICMP. 
There is none for SCTP. If there was one we could debate this. But right now it's 
just impossible to say "support SCTP" without saying how this is done.

>     Moreover, your logic in this requirement to me
>     doesn't hold.  There is a substantial difference between a NAT within an
>     administrative domain that can be managed by the subscriber, and one that
>     realistically cannot be.  Therefore, the requirements upon CGNs should be
>     *stronger*.  Of course this should be balanced by other considerations, such
>     as keeping the Internet growing, but the logic needs to be exposed.  For
>     instance, it may not be possible to safeguard certain IPSEC deployments.

Each of the requirements in our draft is imposed on CGNs but not on other NATs, 
while other NAT-generic requirements that are found in existing RFCs must still 
be obeyed by CGNs. To me it is clear that CGNs have a stricter set of 
requirements to fulfill.

>   * Req10: §14.1.1 of draft-ietf-pcp-base-16 states that failure to segment of
>     traffic opens attacks.  Why was a requirement not added to address this?

In a nutshell: The PCP draft already covers this. We don't need to repeat it. If 
this is not true, then it needs to be addressed in the PCP draft.

 From the PCP draft's section 14.1:

    PCP Servers that comply with the Simple Threat Model and do not
    implement a PCP security mechanism described in Section 14.2 MUST
    enforce the constraints described in the paragraph above.

>   * Req13: Question; if destination addresses and ports are not logged, is there
>     sufficient information to determine a UNIQUE mapping necessary for LI
>     purposes?  Put another way, is the mapping a 3-tuple or a 5-tuple?

REQ-1 mandates support for the usual BEHAVE requirements for TCP, UDP, and ICMP. 
These include the requirement that a NAT (CGN or not) adopt so-called 
Endpoint-Independent Mapping behaviour, meaning that there must be a one-to-one 
mapping between an internal source address+port and an external source 
address+port. This would correspond to your "3-tuple" description.

>   * This requirements document should be reviewed by game developers to get their
>     PoV.  As I understand it, they don't do pcp, but more uPnP, ice & stun.
>     Perhaps that's just a timing thing.

Because of REQ-1, a CGN needs to support the usual BEHAVE requirements for TCP, 
UDP, and ICMP. These RFCs, in their time, have been reviewed by game developers. 
Adding PCP only makes game developers' lives easier.

UPnP cannot work with a CGN as it is designed to work on a local link, whereas a 
CGN is often multiple hops away.

> *Minor issues*
>
>   * I understand that traditional telcos might not be the only ones to offer CGN,
>     the definition of a CGN seems strained, particulary as when relates to
>     "administrative entity".  This may be in part due to the expansion of scope
>     of what is trying to be solved.  I have no great suggestion for you here.

I've personally started thinking of a CGN in terms of a "multi-subscriber NAT". 
That's the key distinction. Most requirements relate to the fact that there are 
multiple subscribers competing for the same resources, and we need to ensure 
fairness.

> *Nits*
>
>   * Yes, there is a terminology section, but NAT un-NATing, and ISPs are not
>     properly defined in their first use in the Introduction.

I expanded the first usage of NAT to "Network Address Translator (NAT) <xref 
target="RFC2663"/>".

I changed "regular, un-NATed IPv4 service" to "regular IPv4 service assigning 
public addresses to subscribers".

I expanded the first usage of ISPs to "Internet Service Providers (ISPs)".

>   * In Figure 1 it may be useful to show IP addresses.

How about this?

                                   .
                                   :
                                   |       Internet
                   ............... | ...................
                                   |       ISP network
                   External pool:  |
                   192.0.2.1/26    |
                               ++------++  External realm
                   ........... |  CGN   |...............
                               ++------++  Internal realm
                        10.0.0.1 |    |
                                 |    |
                                 |    |    ISP network
                   ............. | .. | ................
                                 |    |  Customer premises
                      10.0.0.100 |    | 10.0.0.101
                         ++------++  ++------++
                         |  CPE1  |  |  CPE2  |  etc.
                         ++------++  ++------++

                (IP addresses are only for example purposes)

                       Figure 1: CGN network topology

>   * Something odd going on with your reference to RFC5382 on tools.ietf.org– no
>     link.  Check source and maybe check with the IETF tools people.

Nice parser bug! ;)

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: Simon Perreault <[email-masked]>
Date: Wed, 14 Dec 2011 10:56:38 -0500

On 2011-12-14 10:54, Dave Thaler wrote:
> Simon Perreault wrote:
>> about why
>> There is none for SCTP. If there was one we could debate this. But right now
>> it's just impossible to say "support SCTP" without saying how this is done.
>
> I think Eliot was suggesting something like saying
> "Note that SCTP is not in this list because there is no RFC at this time on
> NAT behavior for SCTP."

Got it, thanks.

Simon

---

From: Dave Thaler <[email-masked]>
Date: Wed, 14 Dec 2011 15:54:07 +0000

-Dave

---

From: Eliot Lear <[email-masked]>
Date: Thu, 15 Dec 2011 08:04:35 +0100

Simon,

Thanks for your comments.  Please see below.

Eliot

On 12/14/11 4:22 PM, Simon Perreault wrote:
>
> I'm sorry, I don't know how to translate that into text. RFC6269
> appears clear to me. Do you have an example of text you would like to
> see?

Don't end with this, but you can start with this.  Because subscribers
do not receive unique IP addresses, Carrier Grade NATs introduce
substantial limitations in communications between subscriber that were
not previously there .  In particular, it is considerably more involved
to establish proxy functionality at the subscriber border.  Some
applications may require substantial enhancements, while some may not
function at all in such an environment.  Please see RFC 6269 for details.
> There are BEHAVE RFCs we can cite regarding NAT behaviour for TCP,
> UDP, and ICMP. There is none for SCTP. If there was one we could
> debate this. But right now it's just impossible to say "support SCTP"
> without saying how this is done.

Dave addressed this.  What about DCCP and RFC 5596?  My main point is
that you explain your logic as you did above.  And...
> Each of the requirements in our draft is imposed on CGNs but not on
> other NATs, while other NAT-generic requirements that are found in
> existing RFCs must still be obeyed by CGNs. To me it is clear that
> CGNs have a stricter set of requirements to fulfill.

That's the point of your draft, I presume, and yet I'm not sure you go
far enough.  My point is that, as you point out, the administrative
nature of NAT has changed.  The end system cannot simply upgrade a NAT
to new proxy functionality.  Therefore I would argue that justification
for NOT requiring functionality is needed.  Therefore, where you say, "
Support for additional transport protocols is OPTIONAL", maybe what you
should say is that " Support for additional transport protocols is
OPTIONAL until such time as their behavior through NATs is
standardized."  That also has the benefit of giving longer life to your
document.

>> segment of
> In a nutshell: The PCP draft already covers this. We don't need to
> repeat it. If this is not true, then it needs to be addressed in the
> PCP draft.
>

Ok.  §14.1 is a bit difficult to parse. I imagine both this draft and
that will undergo a SAAG review.

> REQ-1 mandates support for the usual BEHAVE requirements for TCP, UDP,
> and ICMP. These include the requirement that a NAT (CGN or not) adopt
> so-called Endpoint-Independent Mapping behaviour, meaning that there
> must be a one-to-one mapping between an internal source address+port
> and an external source address+port. This would correspond to your
> "3-tuple" description.

Ok, thanks.
> Because of REQ-1, a CGN needs to support the usual BEHAVE requirements
> for TCP, UDP, and ICMP. These RFCs, in their time, have been reviewed
> by game developers. Adding PCP only makes game developers' lives easier.

Probably.  Has anyone asked them for their opinion?  That's what I'm
suggesting.

>
> UPnP cannot work with a CGN as it is designed to work on a local link,
> whereas a CGN is often multiple hops away.

I get that.  Another reason to check with the gamers.

> I've personally started thinking of a CGN in terms of a
> "multi-subscriber NAT". That's the key distinction. Most requirements
> relate to the fact that there are multiple subscribers competing for
> the same resources, and we need to ensure fairness.

Right.  I'd be careful with the word "fairness", but I get your point.
> I expanded the first usage of NAT to "Network Address Translator (NAT)
> <xref target="RFC2663"/>".
>
> I changed "regular, un-NATed IPv4 service" to "regular IPv4 service
> assigning public addresses to subscribers".
>
> How about this [diagram]?

Ok, and use a legend.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 15 Dec 2011 12:57:16 -0500

On 2011-12-15 02:04, Eliot Lear wrote:
>> I'm sorry, I don't know how to translate that into text. RFC6269 appears clear
>> to me. Do you have an example of text you would like to see?
>
> Don't end with this, but you can start with this.  Because subscribers do not
> receive unique IP addresses, Carrier Grade NATs introduce substantial limitations
> in communications between subscriber that were not previously there .  In
> particular, it is considerably more involved to establish proxy functionality at
> the subscriber border.  Some applications may require substantial enhancements,
> while some may not function at all in such an environment.  Please see RFC 6269
> for details.

Tweaked a bit, gives this:

      <t>Because subscribers do not receive unique IP addresses, Carrier Grade
        NATs introduce substantial limitations in communications between
        subscribers and with the rest of the Internet. In particular, it is
        considerably more involved to establish proxy functionality at the border
        between internal and external realms.  Some applications may require
        substantial enhancements, while some others may not function at all in
        such an environment.  Please see <xref target="RFC6269"/> for
        details.</t>

>> There are BEHAVE RFCs we can cite regarding NAT behaviour for TCP, UDP, and
>> ICMP. There is none for SCTP. If there was one we could debate this. But right
>> now it's just impossible to say "support SCTP" without saying how this is done.
>
> Dave addressed this.  What about DCCP and RFC 5596?  My main point is that you
> explain your logic as you did above.  And...

You're right, there is an RFC specifying NAT behaviour for DCCP: RFC5597.

On the one hand, as a probable future CGN captive, I'm tempted to say "all CGNs 
MUST support RFC5597!"

On the other, I know it would probably be a frivolous requirement that won't get 
implemented.

*sigh*

Then there is also this: draft-ietf-dccp-udpencap-09

Here's a proposal: add a sub-requirement saying something like "If a CGN forwards 
DCCP packets, then it MUST support [RFC5597]."

Simon

---

From: Eliot Lear <[email-masked]>
Date: Fri, 16 Dec 2011 07:29:13 +0100

Hi Simon,

Just to be clear, I'm not asking you to specifically support any
protocol, but to explain your logic as to what your requirements are. 
If you and the working group decide that it is not practical for one
reason or another to support DCCP (or any other protocol) that's fine. 
Just expose your logic.

Eliot

On 12/15/11 6:57 PM, Simon Perreault wrote:
>>> appears clear
>>> UDP, and
>> that you
> On the one hand, as a probable future CGN captive, I'm tempted to say
> "all CGNs MUST support RFC5597!"
>
> On the other, I know it would probably be a frivolous requirement that
> won't get implemented.
>
> *sigh*
>
> Here's a proposal: add a sub-requirement saying something like "If a
> CGN forwards DCCP packets, then it MUST support [RFC5597]."
>
> Simon

---

From: Eliot Lear <[email-masked]>
Date: Fri, 16 Dec 2011 07:43:51 +0100

Shin,

On 12/16/11 3:26 AM, Shin Miyakawa wrote:
>
> We know CGN is quite evil device which produces many bad problems.
>
> I really would like to every one know that our intension is not to make
> CGN perfect, but just finish it as a quick drug (I do not want to
> say it is relief) as less bad as possible.

I'm not asking you to recount the whole debate.  I was asked to review
the draft as part of the Apps Directorate.  It would be grossly remiss
of me to not say that this won't impact applications.  It will, and in a
substantial way.  Simon's text is acceptable to me.

Regards,

Eliot

---

From: Shin Miyakawa <[email-masked]>
Date: Fri, 16 Dec 2011 15:59:58 +0900 (JST)

Eliot,

> the draft as part of the Apps Directorate.  

OK. 

> It would be grossly remiss of me to not say that this won't impact 
> applications.  It will, and in a substantial way.  
> Simon's text is acceptable to me.

I really thank you again for your kind and professional response. 
We really appreciate it.

Best wishes,

Shin

---

From: Shin Miyakawa <[email-masked]>
Date: Fri, 16 Dec 2011 11:26:49 +0900 (JST)

Folks,

First of all, I really thank Simon very much for his quick and
good response, I really think as just Simon wrote.
Also thank you very much Eliot for your valuable comments.

Because Simon has already responded as just I want to tell,
I'd like to make just a short comment about how we think on this draft,
as one of the authors of it.

Eliot:
>> do not receive unique IP addresses, Carrier Grade NATs introduce substantial
>> limitations in communications between subscriber that were not previously there .

CGN is the device belongs to so called "the dark side of the Force", I belive.
And then, just like Master Yoda said,
IT IS NOT STRONGER, But it's QUICKER, EASIER, and MORE SEDUCTIVE.

  (From Quate:Yoda Home Page at http://starwars.wikia.com/wiki/Quote:Yoda
   Luke:"Is the dark side stronger?"
   Yoda:"No,no,no. Quicker, easier, more seductive.")

I strongly believe that Good Jedi must use IPv6,
to protect original goodness of the Internet Protocol whose nature is
based on the End to End transparent communication principle.

Even I am one of the authors of CGN and Shared Address Space 
related drafts which cause many discussions in IETF community, 
but I AM a long time IPv6 guy.

But at the same time, from network operator's point of view
(I am working for one internet network provider), 
many vendors on the Earth have already implemented CGN devices,
and many operators have already installed those into their network
because simply they need to do so for now.

So please let this work completed once quickly as much as possible
to limit (too bad) CGN implementation into the network.

>> In particular, it is considerably more involved to establish proxy
>> functionality at the subscriber border.  
>> Some applications may require substantial enhancements,
>> while some may not function at all in such an environment. 

Then, such a application can not just go through CGN. 
That's fine for me, personally.
Let us move to IPv6 !

# I am sending this E-mail from my environment which is fully 
# v4-v6 dual stack at the commercial grade.

Best wishes,

Shin Miyakawa, Ph.D
Director, Internet Protocol Technology, Innovative IP Architecture Center /
Corporate Planning Department (concurrent position)
NTT Communications Corporation
Gran Park Tower 17F
3-4-1 Shibaura, Minato-ku, Tokyo 108-8118 Japan
E-mail:[email-masked] / [email-masked] / [email-masked]
TEL: +81-50-3812-4695, FAX: +81-3-5439-0490
Guest Professor, Japan Advanced Institute of Science and Technology
Visiting Researcher, SFC Lab. KEIO University
WIDE Project