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

[Simon Perreault <[e-mail]>]

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

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

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

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