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

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