Diameter Network Address and Port Translation Control Application
draft-ietf-dime-nat-control-17

[Ballot discuss]
Referring to version -17 of the draft

Most of my points have been addressed, but I could not find the text part below in draft -17 which was suggested by the authors by email:
"When DNCA application on NAT device detects (using the above mechanism)
that the NAT-controller application has failed, it will trigger clearing of
all the NAT-bindings after a grace period that is configurable on the
NAT-device. When DNCA application within NAT-controller detects failure of
DNCA peer within NAT-device, it may try to reestablish DNCA sessions
associated with that peer or disconnect corresponding access sessions."

I guess the above text should replace this part:
"The DNCA Diameter peer within the NAT-device is unreachable or [...]"

[Ballot discuss]
Referring to version -17 of the draft

Most of my points have been addressed, but I could find the text part below in draft -17 which was suggested by the authors:
"When DNCA application on NAT device detects (using the above mechanism)
that the NAT-controller application has failed, it will trigger clearing of
all the NAT-bindings after a grace period that is configurable on the
NAT-device. When DNCA application within NAT-controller detects failure of
DNCA peer within NAT-device, it may try to reestablish DNCA sessions
associated with that peer or disconnect corresponding access sessions."

I guess the above text should replace this part:
"The DNCA Diameter peer within the NAT-device is unreachable or [...]"

[Ballot discuss]
Referring to version -15 of the draft

The below has been discussed with the authors and I'm waiting for an update of the draft:

What happens when the DNCA peer in the NAT device crashes. This seems to be described at the end of Section 4.6

  o  The DNCA Diameter peer within the NAT-device is unreachable or
      down and NCR fails to get a response.  Handling of this case
      depends on the actual service offering of the service provider.
      The service provider could for example choose to stop offering
      connectivity service.

This is really weak from an operational view, i.e., a crashed DNCA peer will leave 'zombie' NAT bindings in the device.

Each installed binding does not have a timeout value after the binding is automatically removed. At least I cannot find any timer in that respect.

There is the "Event-Timestamp indicates the binding creation time.    If NAT-Control-Binding-Status is set to Removed, Event-Timestamp indicates the binding removal time"

However, this is not a timer which takes care that bindings are automatically removed, if nobody else is doing this.



Some other questions left open by this draft:
- What happens if a requested NAT binding is in conflict with an already installed NAT binding or local configuration policy?
- Section 3.3,
  "This is to ensure that NAT-devices
  controlled by multiple NAT-controllers do not receive conflicting
  control requests for a particular endpoint, or would be unclear which
  NAT-controller to send accounting information to."
  But what happens if a DNCA NAT is receiving conflicting control requests?
- what happens if DNCA has installed a binding which is also owned by some other entity? This can happen, but the question is if what happens with the NAT binding in the NAT itself, if the binding is removed from DNCA? How are bindings differentiated?  Other approaches, such as SIMCO and  the MIDCOM MIB introduce the onwership of the binding, allowing to identify which agent is owning the binding. This allows also implementations to have multiple owners for the same binding.
- How would you express such ownership?

[Ballot discuss]
PARTIALLY updated for -15-

I think this proposal as written would have a negative effect on network operations and network security.

I have updated my discuss to provide action items, to make my concerns more actionable, and have raised a couple issues related to new text.

1) Traditionally, AAA is about authenticating the user, authorizing access to a
service, and usage accounting. AAA often specifies constraints as part of the
authorization; If the provider cannot meet the authorization constraints, the
NAS rejects the request for service. The information that Diameter has is
appropriate to making an accept/reject decision to a user request for service

This proposal is fundamentally different - it modifies the configuration of a remote NAT device to help the user enable the service. However, a Diameter server has a very limited view of the current operational state of the network, and I think it may lack the necessary perspective to
provision/configure devices without impacting the security and operation of other protocols
in the network.

Action item: This draft needs more discussion of the operational issues, especially the lifetime and persistence of NAT configurations put into place for a Diameter session.

2) This document needs to discuss security issues related to modifying device configurations, and
the possible misconfiguration of technologies like firewalls and NATs has the
potential problem of cascading security vulnerabilities. MIDCOM went into great detail
about the security issues involved in multi-party provisioning of middleboxes.
RFC4008 security considerations discusses the sensitivity of writable objects,
their potential for abuse, and the recommendation of using SNMPv3 security
mechanisms to provide access control to the sensitive objects.

The security considerations in this draft are all about securing the message
between Diameter server and client, but not about securing access control to the data and
policies being configured. If this proposal was designed to be about
authenticating a user, authorizing a session, and usage accounting, to determine
reject/accept status, without provisioning the device, a discussion of Diameter message
security might be adequate.

Diameter typically authenticates and authorizes a user-based session, whereas NAT configuration is usually based on host addresses and ports. Multiple users can reside at the same host. Similar to 802.1X, other users can "piggyback" on the authorized user session to leverage the host-to-NAT configuration. 

Action item: the security considerations section needs to discuss
access control issues related to modifying a device's provisioning/configuration
database, including sensitivity of the data, potential impact to a network, and
recommended approaches to mitigate data-access vulnerabilities.

Action item: This draft should probably at least recommend a mandatory-to-implement
configuration protocol, so the interaction between the Diameter request for
configuration of a NAT, and the protocol used to configure a NAT could be evaluated,
especially the trust domain assumptions. (For example, should a Diameter server
running in an AT&T network authorize, for one of AT&T's users, changing the
configuration of a NAT device in a Deutsch Telecom network?

Action item: this draft should discuss the security implications of authorizing a session for one user/application, and the access this could permit for other users/applications at the same host, using the same address and/or port.

3) there is no discussion of coexistence issues between this new proposed
standard for configuring NATs and the existing IETF standards for configuring
NATs, such as the MIDCOM-MIB and the NAT-MIB. There is no discussion of
potential coexistence issues between this proposal and stateful translation
(RFC6146), and other IETF behave-WG approaches.

Action item: this document needs to discuss coexistence if it can be deployed
simultaneously with other IETF standards for configuring NATs, such as STUN, PCP, and SNMP.

draft-brockners-nat-control-protocols-review-00.txt discusses other standards
work that is ongoing in other standards organizations.

Action item: This document should discuss coexistence issues that might occur
with these other efforts at standardizing NAT configuration.

4)The model discussed in the draft appears to assume there is only one NAT device
in the domain. See 3.3., for example.

In contrast, the models in the Behave WG allow for multiple NAT devices.
The models in MIDCOM assume there may be multiple.
If DNCA is going to be touted as a MIDCOM protocol, the explicit prohibition in this draft seems to fail to meet requirements for multiple MIDCOM peering relationships (RFC 4097 2.1.2 and 2.1.3 and 2.1.4).

Action item: This document needs to discuss the operational and security issues related to having multiple NAT devices, and/or multiple NAT controllers.

5) -11- has expanded the query capability in section 1, bullet 5, to allow a query for NAT-bindings belonging to multiple end-points on the NAT device.
      "This feature can be used by an
      entity to find NAT-bindings belonging to one or multiple
      endpoints on the NAT-device. The entity is not required to
      create a DNCA control session to perform the query, but would
      obviously still need to create a Diameter session complying to
      the security requirements."
The security requirements appear to be:
      "DNCA Diameter peers SHOULD have a mutual trust setup.  This document
  does not specify a mechanisms for authorization between the DNCA
  Diameter peers.  The DNCA Diameter peers SHOULD be provided with
  sufficient information to make an authorization decision.  The
  information can come from various sources, for example the peering
  devices could store local authentication policy, listing the
  identities of authorized peers."

Action item: The security considerations section should discuss the implications of allowing a DNCA peer to query for NAT bindings that are not associated with an authorized user session.

Action item: the document needs to be clear who provides the nat binding information. Is this information provided by the NAT device, or the Diameter client based on active user sessions authorized by the Diameter server?

6) in 13.1, step 8, sets a specific mapping for port 80, but then says "Traffic with source IP-address
      192.0.2.1 and a source port different from 80 will be translated
      to IP-address 198.51.100.1 and a port chosen by the NAT-device.
Action item: explain why traffic for ports other than 80 is given such access, when such access was not specifically requested?

7) There are 54 TBDs in -13-. They should be accompanied by RFCEditor notes with instructions to replace the TBDs. The single marker "TBD" is used throughout, to refer to **different** values that are assigned by IANA.  in 6.2, TBD refers to the command code for NAT-Control-Answer;  in 8.2.2, it refers to the RESOURCE_FAILURE value of the Result-Code AVP; in 8.2.3, it refers to the UNKNOWN_BINDING_RULE_NAME value of the Result-Code AVP, and so on. These different uses should be clarified to prevent mistakes during IANA assignments and subsequent RFC editing.

Action item: Make TBDs unambiguous so the RFC editor can determine which TBD needs to be replaced by which value.

8) section 1, bullet 6 discusses a global endpoint identifier, where endpoints are identified by one or more identifiers, such as IP address, VLAN ID, or interface identifier. It appears the description of a globally unique sessionID is actually unique for a user session between a Diameter server and Diameter client. It is unclear how one would assure that the "session" between the Diameter client and the NAT device had a globally unique identifier, and that the identifier used between Diameter server/client was uniquely mapped to the identifier between Diameter client and NAT device. This could impact such things as NAT logging, and information gotten from the NAT device for accounting for a Diameter server/client/user session.

Action item: explain how an identifier can be guaranteed to be globally unique, and interoperable, if it can be based on different values, such as IP address, VLAN ID, or interface identifier.

Action item: explain how/whether there is a globally unique identifier between the Diameter client session and the NAT binding at the NAT device, and how it corresponds to the globally unique Diameter sessionID.

Action item: discuss the operational and security implications if there is not a guaranteed globally unique identifier that helps map between the Diameter sessionID and the associated NAT bindings.

9) section 4.4 says the session-related nat binding MUST be removed when a session terminates. But this is where the mismatch between user-session and host-address-binding becomes important. Multiple users can have sessions on the same host, and each session would generate the same host-address binding. It is unclear whether the technology used to install the binding on the NAT device identifies the associated user session. If two users cause the creation of a shared binding, REQUIRING the removal of the binding when one session terminates would cause the second session to end up with no binding. That is part of why it is important to understand how the protocol that will be used to actually install the binding works.

Additionally, it is possible that bindings can be created without using Diameter to do so, such as using a CLI or SNMP. If Diameter subsequently requests the same binding and it is created, then removing the binding on Diameter session termination could impact device configuration done by other protocols. The other protocols might have created bindings for specific operational or security reasons. So those possible issues of coexistence need to be discussed (see previous bullets).

[Ballot discuss]
updated for -13-

I think this proposal as written would have a negative effect on network operations and network security.

I have updated my discuss to provide action items, to make my concerns more actionable, and have raised a couple issues related to new text.

1) Traditionally, AAA is about authenticating the user, authorizing access to a
service, and usage accounting. AAA often specifies constraints as part of the
authorization; If the provider cannot meet the authorization constraints, the
NAS rejects the request for service. The information that Diameter has is
appropriate to making an accept/reject decision to a user request for service

This proposal is fundamentally different - it modifies the configuration of a remote NAT device to help the user enable the service. However, a Diameter server has a very limited view of the current operational state of the network, and I think it may lack the necessary perspective to
provision/configure devices without impacting the security and operation of other protocols
in the network.

Action item: This draft needs more discussion of the operational issues, especially the lifetime and persistence of NAT configurations put into place for a Diameter session.

2) This document needs to discuss security issues related to modifying device configurations, and
the possible misconfiguration of technologies like firewalls and NATs has the
potential problem of cascading security vulnerabilities. MIDCOM went into great detail
about the security issues involved in multi-party provisioning of middleboxes.
RFC4008 security considerations discusses the sensitivity of writable objects,
their potential for abuse, and the recommendation of using SNMPv3 security
mechanisms to provide access control to the sensitive objects.

The security considerations in this draft are all about securing the message
between Diameter server and client, but not about securing access control to the data and
policies being configured. If this proposal was designed to be about
authenticating a user, authorizing a session, and usage accounting, to determine
reject/accept status, without provisioning the device, a discussion of Diameter message
security might be adequate.

Diameter typically authenticates and authorizes a user-based session, whereas NAT configuration is usually based on host addresses and ports. Multiple users can reside at the same host. Similar to 802.1X, other users can "piggyback" on the authorized user session to leverage the host-to-NAT configuration. 

Action item: the security considerations section needs to discuss
access control issues related to modifying a device's provisioning/configuration
database, including sensitivity of the data, potential impact to a network, and
recommended approaches to mitigate data-access vulnerabilities.

Action item: This draft should probably at least recommend a mandatory-to-implement
configuration protocol, so the interaction between the Diameter request for
configuration of a NAT, and the protocol used to configure a NAT could be evaluated,
especially the trust domain assumptions. (For example, should a Diameter server
running in an AT&T network authorize, for one of AT&T's users, changing the
configuration of a NAT device in a Deutsch Telecom network?

Action item: this draft should discuss the security implications of authorizing a session for one user/application, and the access this could permit for other users/applications at the same host, using the same address and/or port.

3) there is no discussion of coexistence issues between this new proposed
standard for configuring NATs and the existing IETF standards for configuring
NATs, such as the MIDCOM-MIB and the NAT-MIB. There is no discussion of
potential coexistence issues between this proposal and stateful translation
(RFC6146), and other IETF behave-WG approaches.

Action item: this document needs to discuss coexistence if it can be deployed
simultaneously with other IETF standards for configuring NATs, such as STUN, PCP, and SNMP.

draft-brockners-nat-control-protocols-review-00.txt discusses other standards
work that is ongoing in other standards organizations.

Action item: This document should discuss coexistence issues that might occur
with these other efforts at standardizing NAT configuration.

4)The model discussed in the draft appears to assume there is only one NAT device
in the domain. See 3.3., for example.

In contrast, the models in the Behave WG allow for multiple NAT devices.
The models in MIDCOM assume there may be multiple.
If DNCA is going to be touted as a MIDCOM protocol, the explicit prohibition in this draft seems to fail to meet requirements for multiple MIDCOM peering relationships (RFC 4097 2.1.2 and 2.1.3 and 2.1.4).

Action item: This document needs to discuss the operational and security issues related to having multiple NAT devices, and/or multiple NAT controllers.

5) -11- has expanded the query capability in section 1, bullet 5, to allow a query for NAT-bindings belonging to multiple end-points on the NAT device.
      "This feature can be used by an
      entity to find NAT-bindings belonging to one or multiple
      endpoints on the NAT-device. The entity is not required to
      create a DNCA control session to perform the query, but would
      obviously still need to create a Diameter session complying to
      the security requirements."
The security requirements appear to be:
      "DNCA Diameter peers SHOULD have a mutual trust setup.  This document
  does not specify a mechanisms for authorization between the DNCA
  Diameter peers.  The DNCA Diameter peers SHOULD be provided with
  sufficient information to make an authorization decision.  The
  information can come from various sources, for example the peering
  devices could store local authentication policy, listing the
  identities of authorized peers."

Action item: The security considerations section should discuss the implications of allowing a DNCA peer to query for NAT bindings that are not associated with an authorized user session.

Action item: the document needs to be clear who provides the nat binding information. Is this information provided by the NAT device, or the Diameter client based on active user sessions authorized by the Diameter server?

6) in 13.1, step 8, sets a specific mapping for port 80, but then says "Traffic with source IP-address
      192.0.2.1 and a source port different from 80 will be translated
      to IP-address 198.51.100.1 and a port chosen by the NAT-device.
Action item: explain why traffic for ports other than 80 is given such access, when such access was not specifically requested?

7) There are 54 TBDs in -13-. They should be accompanied by RFCEditor notes with instructions to replace the TBDs. The single marker "TBD" is used throughout, to refer to **different** values that are assigned by IANA.  in 6.2, TBD refers to the command code for NAT-Control-Answer;  in 8.2.2, it refers to the RESOURCE_FAILURE value of the Result-Code AVP; in 8.2.3, it refers to the UNKNOWN_BINDING_RULE_NAME value of the Result-Code AVP, and so on. These different uses should be clarified to prevent mistakes during IANA assignments and subsequent RFC editing.

Action item: Make TBDs unambiguous so the RFC editor can determine which TBD needs to be replaced by which value.

8) section 1, bullet 6 discusses a global endpoint identifier, where endpoints are identified by one or more identifiers, such as IP address, VLAN ID, or interface identifier. It appears the description of a globally unique sessionID is actually unique for a user session between a Diameter server and Diameter client. It is unclear how one would assure that the "session" between the Diameter client and the NAT device had a globally unique identifier, and that the identifier used between Diameter server/client was uniquely mapped to the identifier between Diameter client and NAT device. This could impact such things as NAT logging, and information gotten from the NAT device for accounting for a Diameter server/client/user session.

Action item: explain how an identifier can be guaranteed to be globally unique, and interoperable, if it can be based on different values, such as IP address, VLAN ID, or interface identifier.

Action item: explain how/whether there is a globally unique identifier between the Diameter client session and the NAT binding at the NAT device, and how it corresponds to the globally unique Diameter sessionID.

Action item: discuss the operational and security implications if there is not a guaranteed globally unique identifier that helps map between the Diameter sessionID and the associated NAT bindings.

9) section 4.4 says the session-related nat binding MUST be removed when a session terminates. But this is where the mismatch between user-session and host-address-binding becomes important. Multiple users can have sessions on the same host, and each session would generate the same host-address binding. It is unclear whether the technology used to install the binding on the NAT device identifies the associated user session. If two users cause the creation of a shared binding, REQUIRING the removal of the binding when one session terminates would cause the second session to end up with no binding. That is part of why it is important to understand how the protocol that will be used to actually install the binding works.

Additionally, it is possible that bindings can be created without using Diameter to do so, such as using a CLI or SNMP. If Diameter subsequently requests the same binding and it is created, then removing the binding on Diameter session termination could impact device configuration done by other protocols. The other protocols might have created bindings for specific operational or security reasons. So those possible issues of coexistence need to be discussed (see previous bullets).

[Ballot discuss]
updated for -13-

I think this proposal as written would have a negative effect on network operations and network security.

I have updated my discuss to provide action items, to make my concerns more actionable, and have raised a couple issues related to new text.

1) Traditionally, AAA is about authenticating the user, authorizing access to a
service, and usage accounting. AAA often specifies constraints as part of the
authorization; If the provider cannot meet the authorization constraints, the
NAS rejects the request for service. The information that Diameter has is
appropriate to making an accept/reject decision to a user request for service

This proposal is fundamentally different - it modifies the configuration of a remote NAT device to help the user enable the service. However, a Diameter server has a very limited view of the current operational state of the network, and I think it may lack the necessary perspective to
provision/configure devices without impacting the security and operation of other protocols
in the network.

Action item: This draft needs more discussion of the operational issues, especially the lifetime and persistence of NAT configurations put into place for a Diameter session.

2) This document needs to discuss security issues related to modifying device configurations, and
the possible misconfiguration of technologies like firewalls and NATs has the
potential problem of cascading security vulnerabilities. MIDCOM went into great detail
about the security issues involved in multi-party provisioning of middleboxes.
RFC4008 security considerations discusses the sensitivity of writable objects,
their potential for abuse, and the recommendation of using SNMPv3 security
mechanisms to provide access control to the sensitive objects.

The security considerations in this draft are all about securing the message
between Diameter server and client, but not about securing access control to the data and
policies being configured. If this proposal was designed to be about
authenticating a user, authorizing a session, and usage accounting, to determine
reject/accept status, without provisioning the device, a discussion of Diameter message
security might be adequate.

Diameter typically authenticates and authorizes a user-based session, whereas NAT configuration is usually based on host addresses and ports. Multiple users can reside at the same host. Similar to 802.1X, other users can "piggyback" on the authorized user session to leverage the host-to-NAT configuration. 

Action item: the security considerations section needs to discuss
access control issues related to modifying a device's provisioning/configuration
database, including sensitivity of the data, potential impact to a network, and
recommended approaches to mitigate data-access vulnerabilities.

Action item: This draft should probably at least recommend a mandatory-to-implement
configuration protocol, so the interaction between the Diameter request for
configuration of a NAT, and the protocol used to configure a NAT could be evaluated,
especially the trust domain assumptions. (For example, should a Diameter server
running in an AT&T network authorize, for one of AT&T's users, changing the
configuration of a NAT device in a Deutsch Telecom network?

Action item: this draft should discuss the security implications of authorizing a session for one user/application, and the access this could permit for other users/applications at the same host, using the same address and/or port.

3) there is no discussion of coexistence issues between this new proposed
standard for configuring NATs and the existing IETF standards for configuring
NATs, such as the MIDCOM-MIB and the NAT-MIB. There is no discussion of
potential coexistence issues between this proposal and stateful translation
(RFC6146), and other IETF behave-WG approaches.

Action item: this document needs to discuss coexistence if it can be deployed
simultaneously with other IETF standards for configuring NATs, such as STUN, PCP, and SNMP.

draft-brockners-nat-control-protocols-review-00.txt discusses other standards
work that is ongoing in other standards organizations.

Action item: This document should discuss coexistence issues that might occur
with these other efforts at standardizing NAT configuration.

6)The model discussed in the draft appears to assume there is only one NAT device
in the domain. See 3.3., for example.

In contrast, the models in the Behave WG allow for multiple NAT devices.
The models in MIDCOM assume there may be multiple.
If DNCA is going to be touted as a MIDCOM protocol, the explicit prohibition in this draft seems to fail to meet requirements for multiple MIDCOM peering relationships (RFC 4097 2.1.2 and 2.1.3 and 2.1.4).

Action item: This document needs to discuss the operational and security issues related to having multiple NAT devices, and/or multiple NAT controllers.

4) -11- has expanded the query capability in section 1, bullet 5, to allow a query for NAT-bindings belonging to multiple end-points on the NAT device.
      "This feature can be used by an
      entity to find NAT-bindings belonging to one or multiple
      endpoints on the NAT-device. The entity is not required to
      create a DNCA control session to perform the query, but would
      obviously still need to create a Diameter session complying to
      the security requirements."
The security requirements appear to be:
      "DNCA Diameter peers SHOULD have a mutual trust setup.  This document
  does not specify a mechanisms for authorization between the DNCA
  Diameter peers.  The DNCA Diameter peers SHOULD be provided with
  sufficient information to make an authorization decision.  The
  information can come from various sources, for example the peering
  devices could store local authentication policy, listing the
  identities of authorized peers."

Action item: The security considerations section should discuss the implications of allowing a DNCA peer to query for NAT bindings that are not associated with an authorized user session.

Action item: the document needs to be clear who provides the nat binding information. Is this information provided by the NAT device, or the Diameter client based on active user sessions authorized by the Diameter server?

5) in 13.1, step 8, sets a specific mapping for port 80, but then says "Traffic with source IP-address
      192.0.2.1 and a source port different from 80 will be translated
      to IP-address 198.51.100.1 and a port chosen by the NAT-device.
Action item: explain why traffic for ports other than 80 is given such access, when such access was not specifically requested?

6) There are 54 TBDs in -13-. They should be accompanied by RFCEditor notes with instructions to replace the TBDs. The single marker "TBD" is used throughout, to refer to **different** values that are assigned by IANA.  in 6.2, TBD refers to the command code for NAT-Control-Answer;  in 8.2.2, it refers to the RESOURCE_FAILURE value of the Result-Code AVP; in 8.2.3, it refers to the UNKNOWN_BINDING_RULE_NAME value of the Result-Code AVP, and so on. These different uses should be clarified to prevent mistakes during IANA assignments and subsequent RFC editing.

Action item: Make TBDs unambiguous so the RFC editor can determine which TBD needs to be replaced by which value.

7) section 1, bullet 6 discusses a global endpoint identifier, where endpoints are identified by one or more identifiers, such as IP address, VLAN ID, or interface identifier. It appears the description of a globally unique sessionID is actually unique for a user session between a Diameter server and Diameter client. It is unclear how one would assure that the "session" between the Diameter client and the NAT device had a globally unique identifier, and that the identifier used between Diameter server/client was uniquely mapped to the identifier between Diameter client and NAT device. This could impact such things as NAT logging, and information gotten from the NAT device for accounting for a Diameter server/client/user session.

Action item: explain how an identifier can be guaranteed to be globally unique, and interoperable, if it can be based on different values, such as IP address, VLAN ID, or interface identifier.

Action item: explain how/whether there is a globally unique identifier between the Diameter client session and the NAT binding at the NAT device, and how it corresponds to the globally unique Diameter sessionID.

Action item: discuss the operational and security implications if there is not a guaranteed globally unique identifier that helps map between the Diameter sessionID and the associated NAT bindings.

[Ballot comment]
The change log is missing info on the changes between -10- and -12-

Additional editorial comments from Dave Thaler should be addressed. See http://research.microsoft.com/en-us/um/people/dthaler/draft-ietf-dime-nat-control-09.pdf

Additional editorial comments from the tsv-dir review should be addressed. http://www.ietf.org/mail-archive/web/dime/current/msg04789.html

[Ballot comment]
(1) Possibly dumb question: Why does this assume that all external
addresses are IPv4?

(2) I agree with Sean's discuss.

--- stuff below used to be discuss

(2) Session IDs need to be hard to guess or else any Diameter node (or
nearby host pretending to be such) could use the query NCR to suck all the
state from a NAT.  Does 3588 mandate that? If not, maybe this spec
should (as an additional requirement). If 3588 does mandate that then
re-iterating it here would maybe be good.

  I've cleared this part since that's a 3588 issue really,
  so any discuss on this should really go to 3588bis. I think it'd
  still be good for this doc to try to do better, e.g. maybe saying
  that hard-to-guess session IDs for DNCA sessions would be a good
  thing.

[Ballot discuss]
(1) Why is the on-demand query feature required? (Section 1, bullet 5.)
This seems to be something that might have significant privacy
implications if abused. There is some text in the security
considerations about this, but I don't see text saying why this is
needed at all.
  Just checking one thing about the change here which adds
  this text:

>        The entity is not required to create a
>        DNCA control session to perform the query.

  That last sentence doesn't mean that the
  security stuff can be skipped for this query, right? (There're
  a lot of changes to the doc, (and of course I forget the
  details anyway;-), so I'm not quite sure what's meant by
  that.

 

(2) cleared

(3) cleared

(4) cleared

[Ballot comment]
18) In 1, It would be good to state in the introduction that this includes NAT64 devices too. And is this only for *stateful* NAT64 functionality, or is there anything herein that would apply to stateless NAT64 functionality?

19) expand acronymns on first use, such as AVPs.

20) TBD is used throughout the document, but it refers to different things. in 6.2, TBD refers to the command code for NAT-Control-Answer; in 8.1, it refers to the Auth-Application-Id for the Diameter NAT Control Application; in 8.2.2, it refers to the RESOURCE_FAILURE value of the Result-Code AVP; in 8.2.3, it refers to the UNKNOWN_BINDING_RULE_NAME value of the Result-Code AVP, and so on. These different uses should be clarified to prevent mistakes during IANA assignments and subsequent RFC editing.

21) Some TBDs refer to the codes for attributes reused from published RFCs (e.g.,  figure 13 reuses attributes from RFC5777, which defines the codes) Why are these TBD?

22) Additional editorial comments from Dave Thaler should be addressed. See http://research.microsoft.com/en-us/um/people/dthaler/draft-ietf-dime-nat-control-09.pdf

23) Additional editorial comments from the tsv-dir review should be addressed. http://www.ietf.org/mail-archive/web/dime/current/msg04789.html

[Ballot discuss]
I understand why a AAA approach to provisioning NATs would appear to be desirable, especially to service providers, but I think this proposal would have a negative effect on network operations, on network security, and on other IETF standards-track protocols.

1) This work seems to duplicate some of the functionality of existing standards (rfc5190 midcom-mib, rfc4008 nat-mib, and possibly others). Will this proposal create two different ways to perform the same task?

In other OAM-related environments, the IESG has stated a clear position; when two standards exist to perform the same tasks, that leads to different communities of support, and a lack of interoperability between those communities. This is considered a failure in the IETF.

The document should clearly explain how this proposal differs from existing standards, why existing standards are inadequate and cannot be extended to perform the task, and why we need an additional standard for configuring NATs. The document should also discuss why this will not result in different non-interoperable communities of support.

2) There are operational issues related to configuration and provisioning, such as handling simultaneous modifications to configurations, that are reasonably well addressed by Netconf (via locking) and SNMP (via atomic SETs and VACM). Diameter wasn't designed to do device configuration; it was designed to do session authorization, and doesn't address these issues of device configuration.

I must admit I was suprprised to find that in 2009, the Diameter charter extended AAA to also include provisioning (and charter text also discusses doing configuration). Personally, I believe adding provisioning to AAA is a mistake. We have existing standards for doing control and configuration and provisioning.

Traditionally, AAA is about authenticating the user, authorizing access to a service, and usage accounting. AAA often specifies constraints as part of the authorization; If the provider cannot meet the authorization constraints, the NAS rejects the request for service. That is fundamentally different than modifying the configuration of the device to constrain the service.

The information that Diameter has is appropriate to making an accept/reject request for service, but a Diameter server has a very limited view of the network, and I think it may lack the necessary perspective to provision/configure devices without impacting the operation of other protocols in the network.

Specifying session-specific constraints in the Diameter message is appropriate, but by modifying configuration of the device, the Diameter proposal now seems to go beyond just authorizing the session being authorized.

I think this draft would need to discuss how to solve operational issues resulting from multiple RADIUS servers modifying a shared device. I think the simplest approach would be to use the traditional AAA model - have the aerver specify the constraints for the session, and have the AAA client reject or accept based on ability to meet those constraints. This can be done without modifying the device configuration.

3) There are security issues related to modifying device configurations, and possible misconfiguration of technologies like firewalls and NATs has the potential problem of cascading vulnerabilites. MIDCOM went into great detail about the security issues involved in multi-party provisioning of middleboxes. RFC4008 security considerations discusses the sensitivity of writable objects, their potential for abuse, and the recommedation of using SNMPv3 security mechanisms to provide access control to the sensitive objects.

The security considerations in this draft are all about securing the message between server and client, but not about securing access control to the data and policies being configured. If this proposal was designed to be about authenticating a user, authorizing a session, and usage accounting, to determine reject/accept status, without provisioning the device, a discussion of message security might be adequate.

I think the security considerations section needs to be expanded to include access control issues related to modifying a device's provisioning/configuration database, including sensitivity of the data, potential impact to a network, and recommended approaches to mitigate data-access vulnerabilities.

4) there is no discussion of coexistence issues between this new proposed standard for configuring NATs and the existing IETF standards for configuring NATs, such as the MIDCOM-MIB and the NAT-MIB. There is no discussion of potential coexstence issues between this proposal and stateful translation (RFC6146), and other IETF approaches.

I think this document needs to discuss coexistence if it can be deployed simultaneously with other IETF standards.

draft-brockners-nat-control-protocols-review-00.txt discusses other standards work that is ongoing in other standards organizations. This document should probably at least acknowledge any coexistence issues that might be likely with these other efforts at standardizing NAT configuration.

5) If this is approved, should the existing standards be declared historic? does this proposal explicitly or inadvertently update any existing standards regarding NAT configuration, or on-the-wire behaviors of NATs?

For example, if Diameter specifies a maximum number of bindings, is MIDCOM expected to abide by that maximum?
For example, if a NAT device does not create NATs requested via MIDCOM or the NAT-MIB, due to the new maximum number of bindings per interface, will this impact the expectations of (i.e., break) applications using other standard protocols, such as an SNMP SET-request to create a new binding in the NAT-MIB?

I think the draft needs to document any impact this proposal would have on other IETF standards (and what that means for the corresponding documents).

===
Here are additional points, raised durng tsvdir and behave chair reviews, that should be addressed. Most just require additional text.

6)The model discussed in the draft appears to assume there’s only one NAT device in the domain. In contrast, the models in the Behave WG allow for multiple. What happens if there are multiple NAT-devices (for failover or load balancing or whatever else)? See 3.3., for example.

7) Security seems to be a MAY. Why not a SHOULD or a MUST?

8) There’s no mention of DoS attack by filling up logs. Is that a concern?

9) Figure 10 in 8.1 is confusing. The column with P’s is labeled “MAY”. But the text says “Indicates the need for encryption” which implies MUST. . Please clarify. I don't understand what the three columns mean - MUST, MAY (where P means encryption needed), and "may encrypt". When "may encrypt" is N, does that mean MUST NOT encrypt or MAY not encrypt?
How should one interpret "P MAY = encryption may be needed for e2e security" AND "may encrypt = N"? Does this mean encryption may be needed for e2e security, but implmenters MUST NOT use encryption?


10) figure 11 in 8.3 seems unclear; some explanatory text would help ensure that interpretations are consistent, and implementations are interoperable. RFC 3588, which defines the AVP flags, does not use a table like this; it uses explanatory text. This document should a) reference section 4 in RFC3588 and b) explain how to read this table.

11) in figure 13, Why do you want a mask rather than a prefix length? Especially for IPv6 (but even for IPv4), use of masks is strongly discouraged.

12) Is the DNCA able to allocate 2 consecutive transport ports? This is sometimes required by legacy RTP/RTCP applications.

13) 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.

14) 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?

15) 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

16) Section 4.6, "The peering entities MUST have built-in redundancy support to recover state in case of failure." Is there a normative reference that describes conformance requirements for this mandatory redundancy support?

17) Section 6.1 and 6.2: This lists parameters which can be included in requests and responses, but these are omitted in Section 4. 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.

A review of this draft by the behave WG chairs has been done. Dave Thaler's comments are below:

http://research.microsoft.com/en-us/um/people/dthaler/draft-ietf-dime-nat-control-09.pdf

or (same content)

http://research.microsoft.com/en-us/um/people/dthaler/draft-ietf-dime-nat-control-09.docx



High level questions:

1)      The model discussed in the draft appears to assume there’s only one NAT device in the domain.  In contrast, the models in the Behave WG allow for multiple.  What happens if there are multiple NAT-devices (for failover or load balancing or whatever else)?

2)      Security seems to be a MAY.  Why not a SHOULD or a MUST?  Using only a MAY warrants an explanation.

3)      There’s no mention of DoS attack by filling up logs.  Is that a concern?



Rest is mostly editorial nits.



I also reviewed it for consistency with RFC 4008 and for consistency with draft-ietf-behave-lsn-requirements, and I didn’t spot any inconsistencies other that in question 1 above.



-Dave

[Ballot discuss]
I understand why a AAA approach to provisioning NATs would appear to be desirable, especially to service providers, but I think this proposal would have a negative effect on network operations, on network security, and on other IETF standards-track protocols.

1) This work seems to duplicate some of the functionality of existing standards (rfc5190 midcom-mib, rfc4008 nat-mib, and possibly others). Will this proposal create two different ways to perform the same task?

In other OAM-related environments, the IESG has stated a clear position; when two standards exist to perform the same tasks, that leads to different communities of support, and a lack of interoperability between those communities. This is considered a failure in the IETF.

The document should clearly explain how this proposal differs from existing standards, why existing standards are inadequate and cannot be extended to perform the task, and why we need an additional standard for configuring NATs. The document should also discuss why this will not result in different non-interoperable communities of support.

2) There are operational issues related to configuration and provisioning, such as handling simultaneous modifications to configurations, that are reasonably well addressed by Netconf (via locking) and SNMP (via atomic SETs and VACM). Diameter wasn't designed to do device configuration; it was designed to do session authorization, and doesn't address these issues of device configuration.

I must admit I was suprprised to find that in 2009, the Diameter charter extended AAA to also include provisioning (and charter text also discusses doing configuration). Personally, I believe adding provisioning to AAA is a mistake. We have existing standards for doing control and configuration and provisioning.

Traditionally, AAA is about authenticating the user, authorizing access to a service, and usage accounting. AAA often specifies constraints as part of the authorization; If the provider cannot meet the authorization constraints, the NAS rejects the request for service. That is fundamentally different than modifying the configuration of the device to constrain the service.

The information that Diameter has is appropriate to making an accept/reject request for service, but a Diameter server has a very limited view of the network, and I think it may lack the necessary perspective to provision/configure devices without impacting the operation of other protocols in the network.

Specifying session-specific constraints in the Diameter message is appropriate, but by modifying configuration of the device, the Diameter proposal now seems to go beyond just authorizing the session being authorized.

I think this draft would need to discuss how to solve operational issues resulting from multiple RADIUS servers modifying a shared device. I think the simplest approach would be to use the traditional AAA model - have the aerver specify the constraints for the session, and have the AAA client reject or accept based on ability to meet those constraints. This can be done without modifying the device configuration.

3) There are security issues related to modifying device configurations, and possible misconfiguration of technologies like firewalls and NATs has the potential problem of cascading vulnerabilites. MIDCOM went into great detail about the security issues involved in multi-party provisioning of middleboxes. RFC4008 security considerations discusses the sensitivity of writable objects, their potential for abuse, and the recommedation of using SNMPv3 security mechanisms to provide access control to the sensitive objects.

The security considerations in this draft are all about securing the message between server and client, but not about securing access control to the data and policies being configured. If this proposal was designed to be about authenticating a user, authorizing a session, and usage accounting, to determine reject/accept status, without provisioning the device, a discussion of message security might be adequate.

I think the security considerations section needs to be expanded to include access control issues related to modifying a device's provisioning/configuration database, including sensitivity of the data, potential impact to a network, and recommended approaches to mitigate data-access vulnerabilities.

4) there is no discussion of coexistence issues between this new proposed standard for configuring NATs and the existing IETF standards for configuring NATs, such as the MIDCOM-MIB and the NAT-MIB. There is no discussion of potential coexstence issues between this proposal and stateful translation (RFC6146), and other IETF approaches.

I think this document needs to discuss coexistence if it can be deployed simultaneously with other IETF standards.

draft-brockners-nat-control-protocols-review-00.txt discusses other standards work that is ongoing in other standards organizations. This document should probably at least acknowledge any coexistence issues that might be likely with these other efforts at standardizing NAT configuration.

5) If this is approved, should the existing standards be declared historic? does this proposal explicitly or inadvertently update any existing standards regarding NAT configuration, or on-the-wire behaviors of NATs?

For example, if Diameter specifies a maximum number of bindings, is MIDCOM expected to abide by that maximum?
For example, if a NAT device does not create NATs requested via MIDCOM or the NAT-MIB, due to the new maximum number of bindings per interface, will this impact the expectations of (i.e., break) applications using other standard protocols, such as an SNMP SET-request to create a new binding in the NAT-MIB?

I think the draft needs to document any impact this proposal would have on other IETF standards (and what that means for the corresponding documents).

[Ballot comment]
I do not understand IPv6 on figures 3 and 4. Are they trying to show
dual-stack operation? If so, why is there only "public IPv4" on the
right side? Or are they trying to show NAT64-type of deployment? If
so, why is there IPv4 on the left side? Please clarify.

[Ballot discuss]
(1) Why is the on-demand query feature required? (Section 1, bullet 5.)
This seems to be something that might have significant privacy
implications if abused. There is some text in the security
considerations about this, but I don't see text saying why this is
needed at all.

(2) Session IDs need to be hard to guess or else any Diameter node (or
nearby host pretending to be such) could use the query NCR to suck all the
state from a NAT.  Does 3588 mandate that? If not, maybe this spec
should (as an additional requirement). If 3588 does mandate that then
re-iterating it here would maybe be good.

(3) 5.1 says that identity MAY be verified and that authorization is
also a MAY. Why are both not SHOULD or MUST? Even within a
"trusted" network, hosts may be compromised, or users may
misbehave.

(4) Security considerations says that it "is assumed" that the DNCA
peers are in the same, "trusted" domain. To me, that implies that this
specification MUST NOT be used outside that scenario, if you have
not defined how to do authentication and authorization in an
interoperable manner.

[Ballot discuss]
This might be somewhat related to Robert's discuss:

According to the security considerations authentication, authorization, integrity, and confidentiality is demanded.  Does this require either IPsec between the NAT-controller and NAT-device (where both are end-points) or directly connected (i.e., no relays/agents) with TLS between the NAT-controller and NAT-device?  Figures 3 and 4 show this but I don't see something that explicitly says this.

[Ballot discuss]
(1) I'm not sure that the Key-Type AVP is well enough specified.  At least
for the RSA-KEM variant, I would have expected to see a set of CMS options
(e.g. are certs to be included or not) would be needed in order to get
interop. (I was offine doing the review and am not familiar enough with
the other options to know if the same issue arises.) Have there been any
implementations of these, and if so, what did they put in the key values?
I also don't get why the RFCs defining the details for Key-Type AVPs
are informative and not normative. If this document defines a protocol
that will result in interop, then they need to be normative I'd have
thought.

(2) Which of the Key-Type(s) are implementers of this expected
to support?

(3) The security considerations need to say something about transporting
keys that are not otherwise protected. I think you need to say that
Keying-Material AVPs that are not suitable to be sent in clear MUST
only be sent between two Diameter nodes using TLS or IPsec unless
all the Diameter nodes on a path are known to be equally trusted.
I'm sure wordsmithing is needed there but don't have time right now
to offer a suggestion. (Sorry) Neither of the RFCs referenced in the
security considerations section say that. I've no idea how far that might
be from the WG's opinion.

[Ballot discuss]
This DISCUSS asks about process and can be quickly resolved.

Has this document been reviewed by the Transport Area; e.g., behave Working Group or the Transport Area Directorate?

[Ballot discuss]
The deployment framework section strongly implies that there will be a single entity acting as the NAT controller. The introduction implies other deployment models, calling out that applications hosted by the service provider may be involved as a NAT controller (the example used is SIP-proxy server deployments).

Is it the case that you expect multiple, perhaps uncoordinated controllers? If so, some discussion in the document seems warranted. Either way, the document should be explicit.

[Ballot discuss]
Why does the number of NAT bindings even need to be controlled?  Why should an ISP have any say in the matter?  This limits the number of concurrent flows and if the IETF is providing a tool to do this, then it should be motivated somehow at the very least.

The ability to control address mappings on behalf of the customer provides a tool that can be abused for redirection and blackholing of traffic.  This document does not seem to recognize that in either the body or the security considerations.

IANA understands that, upon approval of this document, there are five
IANA Actions that need to be completed.

First, in the command code subregistry of the Authentication,
Authorization, and Accounting (AAA) Parameters registry located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml

two new registrations will be made as follows:

Code Value: tbd1
Name: NAT-Control-Request (NCR)
Reference: [ RFC-to-be ]

Code Value: tbd2
Name: NAT-Control-Answer (NCA)
Reference: [ RFC-to-be ]

Second, in the AVP Codes subregistry of the Authentication,
Authorization, and Accounting (AAA) Parameters registry located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml

the following new registrations will be made as follows:

Code Value Name Reference
tbd3 NC-Request-Type
tbd4 NAT-Control-Install { RFC-to-be ]
tbd5 NAT-Control-Remove { RFC-to-be ]
tbd6 NAT-Control-Definition { RFC-to-be ]
tbd7 NAT-Internal-Address { RFC-to-be ]
tbd8 NAT-External-Address { RFC-to-be ]
tbd9 Max-NAT-Bindings { RFC-to-be ]
tbd10 NAT-Control-Binding-Rule { RFC-to-be ]
tbd11 Duplicate-Session-Id { RFC-to-be ]
tbd12 NAT-Control-Record { RFC-to-be ]
tbd13 NAT-Control-Binding-Status { RFC-to-be ]
tbd14 Current-NAT-Bindings { RFC-to-be ]

Third, in the Result-Code AVP Values (code 268) - Transient Failures
subregistry located in the Authentication, Authorization, and Accounting
(AAA) Parameters registry located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml

the following Result-Code AVP value is to be added:

Code Value: Name: Reference:
4xxx RESOURCE_FAILURE [ RFC-to-be ]

Fourth, in the Result-Code AVP Values (code 268) - Permanent Failure
subregistry located in the Authentication, Authorization, and Accounting
(AAA) Parameters registry located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml

the following new Result-Cdoe AVP values are to be added:

Code Value: Name: Reference:
5xxx UNKNOWN_BINDING_RULE_NAME [ RFC-to-be ]
5xxx BINDING_FAILURE [ RFC-to-be ]
5xxx MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT [ RFC-to-be ]
5xxx SESSION_EXISTS [ RFC-to-be ]
5xxx INSUFFICIENT_CLASSIFIERS [ RFC-to-be ]

Fifth, in the Application ID subregistry located in the Authentication,
Authorization, and Accounting (AAA) Parameters registry located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml

the following new Application ID is to be added:

ID Value: tbd
Name: Diameter NAT Control Application
Reference: [ RFC-to-be ]

IANA understands that these five actions are all that are required to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Diameter Network Address and Port Translation Control Application) to Proposed Standard


The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Diameter Network Address and Port Translation Control Application'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-03-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dime-nat-control/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dime-nat-control/

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

        --
        Jouni Korhonen (jouni.korhonen@nsn.com, jouni.nospam@gmail.com)
        is the Document Shepherd, Dime co-chair. He has done a review
        on the document and believes it is ready to be forwarded to
        IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

        --
    The document has had an extensive review by the DIME WG. The
    document should still be reviewed by the PCP WG and BEHAVE WG
    for NAT considerations. These reviews can be done during the
    IETF LC.
   
        The shepherd has reviewed the document himself and has no
        issue with it. Nor the shepherd has issues with the reviews
        done by others.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

        --
        No.


  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

        --
        No.


  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

        --
        There is Dime WG consensus behind the document.


  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

        --
        No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

        --
        The shepherd has checked the document with the idnits tool and
        found no issues. The document does not need MIB doctor review.
        The document does not contain any media and URI types.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

        --
        References are split accordingly and there are no references
        to documents with unclear status or are in progress.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol

        --
        Yes.

        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If

        --
        Yes, however, this document does not define new IANA
        registries.

        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

        --
        This document does not define new IANA registries.


  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

        --
        Yes. Note that the ABNF used in this document follows the
        modified ABNF syntax defined in RFC3588.
       
       
  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

        --
        This document defines a Diameter NA(P)T Control Application (DNCA).
        The use of the DNCA allows a simple integration of the NAT device
        management into the existing AAA environment of Internet Service
        Provider.
       
        The Diameter application runs between a DNCA Agent on the
        NAT device and the DNCA Manager (either collocated in a NAS
        device or in a AAA server). The DNCA is used to provide advanced
        management of NAT devices, NAT bindings and NAT related accounting.       

    Working Group Summary

        ---
        The document spent well over a year in the WG. However, the authors
        actively kept the document progressing and improving. The document
        is a result of collaborative WG work.

    Document Quality

        ---
        There is currently no publicly announced implementations of the
        protocol. The document itself is solid, well written and in places
        goes into level of details not often seen in Diameter Application
        describing documents.