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

[Martin Stiemerling <[e-mail]>]

Hi Frank, all,

This all looks good, i.e., my comments have been addressed.

Danke schön/Thanks 

  Martin

> -----Original Message-----
> From: Frank Brockners (fbrockne) [mailto:[e-mail]]
> Sent: Friday, September 02, 2011 6:20 PM
> To: Martin Stiemerling; [e-mail];
> [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: 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: [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