Re: [radext] OPS-DIR review of draft-ietf-radext-ip-port-radius-ext-11
<mohamed.boucadair@orange.com> Wed, 05 October 2016 14:05 UTC
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org
Delivered-To: radext@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id E16CA129729; Wed, 5 Oct 2016 07:05:29 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA1E12972D; Wed, 5 Oct 2016 07:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.614
X-Spam-Level:
X-Spam-Status: No, score=-5.614 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQNM_rqsoIES; Wed, 5 Oct 2016 07:05:25 -0700 (PDT)
Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB207129729; Wed, 5 Oct 2016 07:05:24 -0700 (PDT)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 54773180FBB; Wed, 5 Oct 2016 16:05:23 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 1F7BE20068; Wed, 5 Oct 2016 16:05:23 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0319.002; Wed, 5 Oct 2016 16:05:22 +0200
From: mohamed.boucadair@orange.com
To: Tim Chown <Tim.Chown@jisc.ac.uk>
Thread-Topic: OPS-DIR review of draft-ietf-radext-ip-port-radius-ext-11
Thread-Index: AQHR+HEowS7Op1qTZUSXToLnElhR2aCQe3BggAm2NSA=
Date: Wed, 05 Oct 2016 14:05:22 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008E3101D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <AMSPR07MB4557B288F324D4DAA4E0D4CD6140@AMSPR07MB455.eurprd07.prod.outlook.com> <787AE7BB302AE849A7480A190F8B933008E220CD@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933008E220CD@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008E3101DOPEXCLILMA3corp_"
MIME-Version: 1.0
Resent-From: alias-bounces@ietf.org
Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org
Resent-Message-Id: <20161005140529.E16CA129729@ietfa.amsl.com>
Resent-Date: Wed, 05 Oct 2016 07:05:29 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/LhY98KFrxmvuCV5SvZHchBJD3c4>
Cc: "draft-ietf-radext-ip-port-radius-ext.all@ietf.org" <draft-ietf-radext-ip-port-radius-ext.all@ietf.org>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>
Subject: Re: [radext] OPS-DIR review of draft-ietf-radext-ip-port-radius-ext-11
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2016 14:05:30 -0000
Hi Tim, FWIW, an updated version that takes into account your review is available online. A diff is available here: https://www.ietf.org/rfcdiff?url1=draft-ietf-radext-ip-port-radius-ext-12&url2=draft-ietf-radext-ip-port-radius-ext-13 Cheers, Med De : mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Envoyé : jeudi 29 septembre 2016 14:17 À : Tim Chown; ops-dir@ietf.org; draft-ietf-radext-ip-port-radius-ext.all@ietf.org Cc : Kathleen Moriarty Objet : RE: OPS-DIR review of draft-ietf-radext-ip-port-radius-ext-11 Hi Tim, (Apologies for the delay to answer the message) Thank you for the review. Please see inline. Cheers, Med De : Tim Chown [mailto:Tim.Chown@jisc.ac.uk] Envoyé : mercredi 17 août 2016 12:23 À : ops-dir@ietf.org<mailto:ops-dir@ietf.org>; draft-ietf-radext-ip-port-radius-ext.all@ietf.org<mailto:draft-ietf-radext-ip-port-radius-ext.all@ietf.org> Objet : OPS-DIR review of draft-ietf-radext-ip-port-radius-ext-11 Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This draft defines three new RADIUS attributes to be used when communicating with a RADIUS server to facilitate the configuration or reporting of IP and port ranges used with a network appliance, typically a CGN, where there is a need to constrain the ports available per customer where IP address sharing is in use. The three RADIUS attributes are: IP-Port-Limit-Info - defines the maximum number of ports available IP-Port-Range - the specific range of port numbers available IP-Port-Forwarding-Map - to configure port forwarding on a NAT/CGN device I would consider the document to be "Ready with Issues". I have some general comments, followed by some specific comments. Note that while I am familiar with RADIUS (from an eduroam context) the draft is not one I was familiar with or followed prior to this review. Thus these comments may have already been addressed. General comments: There are at least two areas in which this document has "creep". One is that it is providing an alternative method to PCP to define port forwarding mappings on a device. So there is an open question as to whether PCP should be the method of choice for this function, or whether we wish to create a new way to establish such mappings. [Med] PCP targets a different deployment model where an application controls its mapping in a CPE, CGN, Firewall, etc. This document targets a deployment where a AAA server is responsible de instructing NAT mappings for a given subscriber. Secondly, two of the new attributes support inclusion of a new TLV, IP-Port-Local-Id, which allows user/device-specific information to be transmitted via RADIUS, such as MAC address or VLAN ID. While this is intended to allow differentiation of users for accounting/identification r, in doing so it adds an additional potential privacy concern into a new RADIUS attribute, depending on specific use cases of the TLV. [Med] The main use case is the deployment where the internal IP address is not sufficient to demux users. We introduced this NEW text in -12: The primary issue addressed by this TLV is that there are CGN deployments that do not distinguish internal hosts by their internal IP address alone, but use further identifiers for unique subscriber identification. For example, this is the case if a CGN supports overlapping private or shared IP address spaces (refer to [RFC1918<https://tools.ietf.org/html/rfc1918>] and [RFC6598<https://tools.ietf.org/html/rfc6598>]) for internal hosts of different subscribers. In such cases, different internal hosts are identified and mapped at the CGN by their IP address and/or another identifier, for example, the identifier of a tunnel between the CGN and the subscriber. In these scenarios (and similar ones), the internal IP address is not sufficient to demultiplex connections from internal hosts. An additional identifier needs to be present in the IP-Port-Range Attribute and IP-Port-Forwarding-Mapping Attribute in order to uniquely identify an internal host. The IP-Port-Local-Id TLV is used to carry this identifier. This is not discussed in the Security Considerations section, but probably should be. [Med] Fair point. We added this text: The IP-Port-Local-Id TLV includes an identifier of which the type and length is deployment and implementation dependent. This identifier might carry privacy sensitive information. It is therefore RECOMMENDED to utilize identifiers that do not have such privacy concerns. I note the new attributes use a number of IPFIX information elements; has the draft considered its relationship to draft-ietf-behave-ipfix-nat-logging-09, which says the "lack of a consistent way to log the data makes it difficult to write the collector applications that would receive this data and process it to present useful information"? This draft is introducing a new method to log such elements; is this a concern at all? [Med] FWIW, one of the co-authors is the main editor of draft-ietf-behave-ipfix-nat-logging. As a reminder, this draft reuses the IPFIX registry because it offers a rich set of elements. Further, this draft does not focues on NAT logging. Of course, some TLV can be used for notification purposes but this is not logging per se. The examples of use cases of the new attributes include both NAT44 devices and CGNs. The document could state more clearly the address sharing scenarios, perhaps with a simplified network element diagram for each example, showing the user/host, CPE/NAT44, and NAT444/CGN? [Med] I'm sure if this will add more clarity to the draft because there are many deployment cases that can be cited. The draft explicitly calls out the CPE case and CGN. Some additional clarity here would be useful (see also comments below). Also, the term "the user" is used in many places in the document where in practice "the customer's CPE" would be more appropriate. [Med] I agree that some occurrences can be replaced easily by subscriber or customer but still "user" is accurate. For example, it is not a customer that initiates a connection but a user (that may be the customer itself or another person that uses the right to invoke the service). In order to avoid overloading the document with such subtleties, we prefer to use "user" in the whole document. Specific comments: NAT64 is mentioned as a use case at the start, but no example is given later in the document. This might add useful value. [Med] Happily! We will update the text accordingly. In Sections 3.2.6, 3.2.7, 3.2.9 and 3.2.10, the IPFIX information elements in the TLV are 16 bit values, but 32 bits are reserved for the element. Similarly the NatEvent element is 8-bit, but has 32 bits reserved. It would be useful if the document stated why these elements are being padded out to 32 bits. [Med] Please check https://tools.ietf.org/html/rfc6158#appendix-A.2.1 In Section 4.1.1, I don't think NAT64 is specifically designed to multiplex users over a smaller number of shared IPv4 addresses, rather its primary design goal is to facilitate access to legacy IPv4 content from IPv6-only networks. The text should be clarified. [Med] I guess you are referring to "over a smaller number of shared IPv4 addresses". "Smaller" is used here to indicate that the external IP address pool is not sufficient to assign a full IPv4 address to each internal host. NAT64 falls into such category. RFC6146 says: "One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients." Also in 4.1.1, do users really have service agreements that state port limits? [Med] There is no assumption in the draft that SLAs include port limits. If they do, I doubt users are aware of them (or care...), and the issue is beyond the scope of this document. [Med] Agree. In 4.1.2, I think you mean "block", not "bulk"? And the comment on "randomization" might fit better in the Security Considerations section if you discuss privacy there (which is presumably what you mean?) [Med] Can be added, indeed. Also in 4.1.2 you discuss the scenario as if it's CGN, but the flow diagram shows only the NAT44 (presumably in the CPE) and not an ISP CGN. [Med] No, the diagram shows a NAT that is collocated with a BNG. This is a CGN case. The same happens in 4.1.3; discussion of CGN and NAT44 interchangeably, without the diagram showing there may (presumably) be mappings to establish at both the user's CPE and the ISP's CGN. [Med] Idem as above
- [radext] OPS-DIR review of draft-ietf-radext-ip-p… Tim Chown
- [radext] OPS-DIR review of draft-ietf-radext-ip-p… Tim Chown
- Re: [radext] OPS-DIR review of draft-ietf-radext-… mohamed.boucadair
- Re: [radext] OPS-DIR review of draft-ietf-radext-… mohamed.boucadair