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

[Eliot Lear <[e-mail]>]

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.