Re: [Dime] tsv-dir review of daft-ietf-dime-nat-control-09

["Frank Brockners (fbrockne)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
Of
> Martin Stiemerling
> Sent: Wednesday, July 20, 2011 3:34 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> 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  [e-mail] 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
> 
> [e-mail]
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime