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

Eliot Lear <lear@cisco.com> Thu, 15 December 2011 07:05 UTC

Return-Path: <lear@cisco.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A16E1F0C43; Wed, 14 Dec 2011 23:05:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.669
X-Spam-Level:
X-Spam-Status: No, score=-109.669 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMLfDoBZGY8c; Wed, 14 Dec 2011 23:05:14 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 060AC1F0C47; Wed, 14 Dec 2011 23:05:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=15878; q=dns/txt; s=iport; t=1323932714; x=1325142314; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=j28B+fDrAS9W4zDzX48sEhdgSrFh0HQFUZTcm5k29/o=; b=BcM68UQUagyL4kBRmpE9XO20XWVsA0eLlx92+WxMq9G+Wd9AgvLuDLbn 6p/EsUnHAUBJWuSLwxWMECqtcIFXdldgUxds01giHo+xCQ2f6TSjvXHjk 6jqer6Ua12G90j1f+PnuFwjyOhtBL63sX+96RHBIVk1LyB60TM/KRTbz1 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFADeb6U6Q/khN/2dsb2JhbABEhQqmIYEFgXIBAQEDARIBECQeAhEBEAkCGAkWCwICCQMCAQIBRQYNAQcBARUJh1iZKQGMXINejXOKcYEWBJR1kis
X-IronPort-AV: E=Sophos; i="4.71,356,1320624000"; d="scan'208,217"; a="123797333"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 15 Dec 2011 07:05:12 +0000
Received: from elear-mac.local (dhcp-10-55-82-123.cisco.com [10.55.82.123]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pBF74fCH019262; Thu, 15 Dec 2011 07:04:44 GMT
Message-ID: <4EE99C03.6050401@cisco.com>
Date: Thu, 15 Dec 2011 08:04:35 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Simon Perreault <simon.perreault@viagenie.ca>
References: <4EE79606.30704@cisco.com> <4EE8BF1F.9080901@viagenie.ca>
In-Reply-To: <4EE8BF1F.9080901@viagenie.ca>
X-Enigmail-Version: 1.3.4
Content-Type: multipart/alternative; boundary="------------040708010900010803060705"
Cc: draft-ietf-behave-lsn-requirements.all@tools.ietf.org, 'IESG' <iesg@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Apps Area Review of draft-ietf-behave-lsn-requirements-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2011 07:05:16 -0000

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

Dave addressed this.  What about DCCP and RFC 5596?  My main point is
that you explain your logic as you did above.  And...
>
>>     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.

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.

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

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

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

Ok, thanks.
>
>>   * 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.

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.

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

Right.  I'd be careful with the word "fairness", but I get your point.
>
>> *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 [diagram]?

Ok, and use a legend.
>
>