Re: [Dime] tsv-dir review of daft-ietf-dime-nat-control-09
<lionel.morand@orange-ftgroup.com> Fri, 09 September 2011 07:27 UTC
Return-Path: <lionel.morand@orange-ftgroup.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A70821F8AA8; Fri, 9 Sep 2011 00:27:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.954
X-Spam-Level:
X-Spam-Status: No, score=-100.954 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_LIST=2.3, 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 KmHPaqwOYRSV; Fri, 9 Sep 2011 00:27:52 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 19E1021F888A; Fri, 9 Sep 2011 00:27:51 -0700 (PDT)
Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 40E318B8009; Fri, 9 Sep 2011 09:31:03 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 2D9297B8003; Fri, 9 Sep 2011 09:31:03 +0200 (CEST)
Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Sep 2011 09:28:40 +0200
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 09 Sep 2011 09:28:38 +0200
Message-ID: <B11765B89737A7498AF63EA84EC9F577CEA18D@ftrdmel1>
In-reply-to: <0D212BD466921646B58854FB79092CEC0689871F@XMB-AMS-106.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-topic: [Dime] tsv-dir review of daft-ietf-dime-nat-control-09
Thread-index: AcxG2jxqScbzP0yQT824oXePckWTcAirVqQgAU5tUHA=
References: <E84E7B8FF3F2314DA16E48EC89AB49F01CF0F684@Polydeuces.office.hd> <0D212BD466921646B58854FB79092CEC0689871F@XMB-AMS-106.cisco.com>
From: lionel.morand@orange-ftgroup.com
To: Martin.Stiemerling@neclab.eu
X-OriginalArrivalTime: 09 Sep 2011 07:28:40.0113 (UTC) FILETIME=[18874210:01CC6EC2]
Cc: tsv-ads@tools.ietf.org, dime@ietf.org, rdroms.ietf@gmail.com, tsv-dir@ietf.org, draft-ietf-dime-nat-control@tools.ietf.org
Subject: Re: [Dime] tsv-dir review of daft-ietf-dime-nat-control-09
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Sep 2011 07:27:53 -0000
Hi Martin, Does this new version of the draft answer your concerns? Regards, Lionel -----Message d'origine----- De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Frank Brockners (fbrockne) Envoyé : vendredi 2 septembre 2011 18:20 À : Martin Stiemerling; draft-ietf-dime-nat-control@tools.ietf.org; dime@ietf.org Cc : tsv-ads@tools.ietf.org; tsv-dir@ietf.org Objet : Re: [Dime] tsv-dir review of daft-ietf-dime-nat-control-09 Martin, thanks for your comments and sorry for the delay in getting the draft updated. We just posted a new revision (draft-ietf-dime-nat-control-11), reflecting your comments. Please see additional comments inline... > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Martin Stiemerling > Sent: Wednesday, July 20, 2011 3:34 PM > To: draft-ietf-dime-nat-control@tools.ietf.org; dime@ietf.org > Cc: tsv-ads@tools.ietf.org; tsv-dir@ietf.org > Subject: [Dime] tsv-dir review of daft-ietf-dime-nat-control-09 > > Hi there, > > I've reviewed this document as part of the transport area directorate's > ongoing effort to review key IETF documents. These comments were > written primarily for the transport area directors, but are copied to > the document's authors for their information and to allow them to > address any issues raised. The authors should consider this review > together with any other last-call comments they receive. Please always > CC tsv-dir@ietf.org if you reply to or forward this review. > > **Executive Summary: > This draft has serious issues, described in the review, and needs to be > rethought. > > **Review comments: > > *General > - There is no place where the prior work of MIDCOM is mentioned. > Is this intentionally and did the WG not know or consider prior work of > the IETF? > MIDCOM is going beyond what this draft is specifying, as it also > includes firewall control, plus some further features, such as learning > about the interfaces used for the MIDCOM server. > What was the reasoning to not reuse MIDCOM or semantics developed for > MIDCOM? ...FB: The question on the relationship of DNCA and MIDCOM was also raised by other reviewers. Following those comments, the relationship of DNCA to MIDCOM was discussed by the DIME WG again at the last IETF in Quebec (the WG had a first round of discussions on this topic when draft-brockners-nat-control- protocols-review-00 was presented). See also IETF 81 DIME notes. Conclusion was that for network management, there can be different protocols, aiming at a similar solution domains. These different protocol follow the deployment requirements of different operators. SNMP and NETCONF were mentioned as examples. DNCA is targeted at deployments which already heavily employ the Diameter protocol for per-subscriber device control (e.g. mobile networks). DNCA qualifies as a MIDCOM protocol, and at the same time offers capabilities for per-subscriber control. It is not there to replace existing solutions, but complement them. If there is interest, the DNCA protocol work could potentially be complemented with a BCP in the ops area, providing additional deployment guidance. Following the outcome of the discussion, we added a paragraph to section 1 to explicitly discuss DNCA as a MIDCOM protocol: With the above capabilities, DNCA qualifies as a MIDCOM protocol [RFC3303], [RFC3304], [RFC5189] for middle boxes which perform NAT. The MIDCOM protocol evaluation [RFC4097] evaluated Diameter as a candidate protocol for MIDCOM. DNCA provides the extensions to the Diameter base protocol [RFC3588] following the MIDCOM protocol requirements, such as the support of NAT-specific rule transport, support for oddity of mapped ports, as well as support for consecutive range port numbers. DNCA adds to the MIDCOM protocol capabilities in that it allows to maintain the reference to an end point representing a user or subscriber in the control operation, enabling the control of the behavior of a NAT-device on a per end point basis. Following the requirements of different operators and deployments, different management protocols are employed. Examples include e.g. SNMP [RFC3411] and NETCONF [RFC6241] which can both be used for device configuration. Similarly, DNCA is complementing existing MIDCOM implementations, offering a MIDCOM protocol option for operators with an operational environment that is Diameter- focused which desire to use Diameter to perform per end point NAT control. > > - The usage of RFC 2119 is missing in parts of the draft, e.g., the > text in Section 4 seems to be meant as mandatory but there is almost no > RFC 2119 language. ...FB: We fixed this in the most recent version, and used RFC 2119 throughout the document. > - Is the DNCA able to allocate 2 consecutive transport ports? This is > sometimes required by legacy RTP/RTCP applications. ...FB: We've updated DNCA to allow for this use (which is also a MIDCOM requirement). This is now reflected with a new AVP: 8.7.10. NAT-External-Port-Style AVP The NAT-External-Port-Style AVP (AVP Code TBD) is of type Enumerated and contains the style to be followed while selecting the external port for a NAT-Binding relative to the internal port. The following values are defined: FOLLOW_INTERNAL_PORT_STYLE (1) External port numbers selected MUST follow the same sequence and oddity as the internal ports of the NAT-bindings. The port odditity is required to support protocols like RTP and RTCP as defined in [RFC3550]. If for example the internal port in a requested NAT-binding is odd numbered then the external port allocated MUST also be odd numbered, and vice versa for an even numbered port. In addition, the sequence of port numbering is maintained: If internal ports are consecutive, then the NAT- device MUST choose consecutive external ports for the NAT- bindings. > > * Detailed review > - Section 1, 1st paragraph, a nit: > "... in their networks to deal with the depletion of available public > IPv4 Addresses". This is one reason out of many. NATs are around for > 10+ years, i.e., way before we were about to run out of IPv4 addresses. ...FB: Agreed. Current text no longer mentions this as exclusive, but makes this a key example: [..] Internet service providers deploy Network Address Translators (NATs) and Network Address and Port Translators (NAPTs) [RFC3022] in their networks. A key motivation for doing so is the depletion of available public IPv4 addresses. [..] > - Section 2, and rest of the document: > The terminology used in this draft is not well documented. There are > NAT bindings, NAT binding rules and predefined NAT binding rules > (templates?). However, the difference is not well documented, even > though I understand the difference. How do you name a NAT binding which > is actually used by a data exchange? ...FB: We cleaned up the language around those, and added two entries to the abbreviation section (e.g. NAT binding rules and predefined binding rules got consolidated into "NAT Binding Predefined template"): NAT-binding or binding: Association of two IP address/port pairs (with one IP address typically being private and the other one public) to facilitate NAT NAT Binding Predefined template: Is a policy template or configuration that is predefined at the NAT-device. It may contain NAT-bindings, IP-address pools for allocating the external IP-address of a NAT-binding, the maximum number of allowed NAT- bindings for end-points, etc. > - Section 3.1, page 8, 1st paragraph, "to increase the efficiency of > the global IPv4 address pool utilization.": > Not sure that this setting is only used for this use case. How about > just writing: > "Figure 2 depicts the deployment scenario where a service provider > places a NAT between the host and the public Internet." ...FB: Thanks. The text now reflects your suggestion. > - It would be good to cite RFC6144-6147 for 6to4 to indicate on what > basis the address family translation is working in this draft. The same > holds true for IPv4. ...FB: The intro section now references NAT related RFCs relevant to DNCA, see below. What I'm not sure about is why you refer to 6to4 (which would be RFC3056) - which I don't really see applicable to DNCA (because there is no translation in 6to4, just tunneling). Internet service providers deploy Network Address Translators (NATs) and Network Address and Port Translators (NAPTs) [RFC3022] in their networks. A key motivation for doing so is the depletion of available public IPv4 addresses. This document defines a Diameter application allowing providers to control the behavior of NAT and NAPT devices that implement IPv4-to-IPv4 network address and port translation [RFC2663] as well as stateful IPv6-to-IPv4 address family translation translation as defined in [RFC2663], [RFC6145], and [RFC6146]. The use of a Diameter application allows for simple integration into the existing Authentication, Authorization and Accounting (AAA) environment of a provider. > - IPv6 to IPv4 translation: I was not able to figure out how such a > signaling would be. There are no examples for this or guidance at all. > - IPv4 to IPv4 translation: It would be good to have one or some few > examples to see how such DNCA messages would look like. ...FB: We've created an entire new section (section 13) showing examples for several uses of DNCA. There are no real differences wrt/ signaling between IPv6 and IPv4. The only real difference is that you'd either define an internal IPv4 or IPv6 address using a respective AVP. > - All figures: The figures are not especially meaningful for the reader > and do not help in my opinion to understand the protocol, but do not > hamper understanding either. > - Section 4.2, page 15, last bullet point starting with "If a NCR > redfines...": > This touches a critical point of what happens if the new number of > allowed bindings is lower than the prior selected number of allowed > bindings. The text is not giving a good guidance of what should happen > in this case and I see it a weak point to let this open to the > discretion of the implementation. For a good specification I would at > least expect a RECOMMENDATION or SHOULD, better a MUST. However, this > comment relates to the lack of RFC 2119 language in this section. ...FB: Agreed. We've updated the bullet using a SHOULD recommendation: o If an NCR redefines the maximum number of NAT-bindings allowed for the endpoint, the new value MUST override any previously defined limit on NAT bindings. It depends on the implementation of the NAT-device on how the NAT-device copes with a case where the new value is lower than the actual number of allocated bindings. The NAT-device SHOULD refrain from enforcing the new limit immediately (that is, actively remove bindings), but rather disallows the establishment of new bindings until the current number of bindings is lower than the newly established maximum number of allowed bindings. > - Section 4.2, page 16, bullet point "If a NCR specifies a new...": > What happens in this case with already binding rules which are > installed and actively used by a data session? Is the data session > stopped and the binding removed? ...FB: We've clarified this by stating that a change of templates should not impact existing sessions: o If an NCR specifies a new NAT Binding Predefined template on the NAT-device, the NAT Binding Predefined template overrides any previously defined rule for the session. Existing NAT-bindings SHOULD NOT be impacted by the change of templates. > - Section 4.3, page 17, bullet "2. Retrieve...": > How does the DNCA peer with the NAT controller know about the available > external IP addresses at the NAT? This is not clear to me. Is this a > feature of another DIAMETER application or is it assumed that the > controller just knows this somehow? ..FB: The NAT-Controller will know this information via configuration and/or through interaction with the overall OSS/BSS systems. More specifically, it is not a feature of DNCA. > - Section 4.4, 1st paragraph, "In response, the DNCA...": > I cannot understand this sentence. ...FB: We're did a bit of editing on section 4.4 to now be more understandable: 4.4. Session Termination Similar to session initiation, session tear down MUST be initiated by the DNCA Diameter peer within the NAT-controller. The DNCA Diameter peer sends a Session Terminate Request (STR) message to its peer within the NAT-device upon receiving a trigger signal. The source of the trigger signal is outside the scope of this document. As part of STR message processing the DNCA Diameter peer within the NAT-device MAY send an accounting stop record reporting all bindings. All the NAT-bindings belonging to the session MUST be removed and the session state MUST be cleaned up. The DNCA Diameter peer within the NAT- device MUST notify its DNCA Diameter peer in the NAT-controller about successful session termination using a Session Terminate Answer (STA) message with Result-Code set to DIAMETER_SUCCESS. Figure 8 shows the protocol interaction between the two DNCA Diameter peers. If a DNCA Diameter peer within a NAT-device receives a STR and fails to find a matching session, the DNCA Diameter peer MUST return a STA with Result-Code set to DIAMETER_UNKNOWN_SESSION_ID. > - Figure 8: The text belonging to this figure does not mention that the > NAT bindings MUST be removed if the STR is received. This is only shown > in the figure. The text seems to be incomplete and also lacking RFC > 2119 language. ...FB: In order to avoid inconsistencies as well as redundancies between figures and text, we've simplified the figures and expanded the text where necessary. The first paragraph of section 4.4. now reads: Similar to session initiation, session tear down MUST be initiated by the DNCA Diameter peer within the NAT-controller. The DNCA Diameter peer sends a Session Terminate Request (STR) message to its peer within the NAT-device upon receiving a trigger signal. The source of the trigger signal is outside the scope of this document. As part of STR message processing the DNCA Diameter peer within the NAT-device MAY send an accounting stop record reporting all bindings. All the NAT-bindings belonging to the session MUST be removed and the session state MUST be cleaned up. The DNCA Diameter peer within the NAT- device MUST notify its DNCA Diameter peer in the NAT-controller about successful session termination using a Session Terminate Answer (STA) message with Result-Code set to DIAMETER_SUCCESS. Figure 8 shows the protocol interaction between the two DNCA Diameter peers. > - Section 4.6, 1st paragraph: What is the redundancy support mentioned > there which is mandatory? Something which is a MUST must be well > documented. I cannot see this here. ...FB: Agreed that asking for "some redundancy mechanism" but not specifying it is confusing at least. Given that state recovery of Diameter peers is not touched upon in other Diameter applications, we decided after discussion with the DIME chairs to remove references to redundancy mechanisms altogether from the document: 4.6. Failure cases of the DNCA Diameter peers This document does not specify the behavior in case the NAT-device and NAT-controller, or their respective DNCA Diameter peers are out of sync or lose state. > - IANA section and IANA points in text: > The use of TBD throughout the draft for IANA code-points and also in > the IANA section is harmful for IANA and also for the draft at best. > Why are you not using meaningful identifiers for code-points and > reference them in the IANA section? The use of generic TBD placeholders > will just create confusion for IANA and for you. ...FB: Per Miguel Garcia's note, IANA seems to understand what is required. > - Section 6.1 and 6.2: I was surprise to see the list of parameters > which can be included in requests and responses, after reading Section > 4, where those parameters are omitted. Given all these parameters and > the lack of explanation in the draft, it seems to be hard for an > implementer to get the link between Section 4 and this. This needs > further explanation in the draft, see also my comment about how IPv6 to > IPv4 translation works and about the missing usage examples. ...FB: Per what I stated above, we've added an entire section 13 to show several examples. In addition, we've added text to section 6 and 8 to make things hopefully easier to understand. > - Section 8.x, broken labels of the tables: > The figures in Section 8.x are actually tables, i.e., their description > is incorrect and broken. ...FB: We're using tables now :-). > - Section 8.5, Figure 13, "Reused QoS-attributes": > Why are the AVP codes set to TBD if they are taken from RFC 5777? E.g., > Direction AVP (AVP Code 514) but not TBD! ...FB: Good catch. We've updated the table accordingly. Best regards, Frank > > > Kind regards > > Martin Stiemerling > > martin.stiemerling@neclab.eu > > NEC Laboratories Europe - Network Research Division NEC Europe Limited > | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | > Registered in England 2832014 > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime
- [Dime] tsv-dir review of daft-ietf-dime-nat-contr… Martin Stiemerling
- Re: [Dime] tsv-dir review of daft-ietf-dime-nat-c… Frank Brockners (fbrockne)
- Re: [Dime] tsv-dir review of daft-ietf-dime-nat-c… lionel.morand
- Re: [Dime] tsv-dir review of daft-ietf-dime-nat-c… Martin Stiemerling