Diameter Network Address and Port Translation Control Application
Note: This ballot was opened for revision 13 and is now closed.
(David Harrington) Discuss
Discuss (2012-03-27 for -15)
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).
Comment (2012-03-27 for -15)
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
(Benoît Claise) Yes
(Dan Romascanu) Yes
(Jari Arkko) No Objection
Comment (2011-07-14 for -** No value found for 'p.get_dochistory.rev' **)
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.
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) (was Discuss) No Objection
(Wesley Eddy) (was Discuss) No Objection
In the abstract, "completion" should be "depletion"
(Adrian Farrel) No Objection
(Stephen Farrell) (was Discuss, No Objection, Discuss) No Objection
I agree with Sean's discuss.
(Russ Housley) No Objection
(Pete Resnick) No Objection
(Peter Saint-Andre) No Objection
(Robert Sparks) (was Discuss) No Objection
(Martin Stiemerling) (was Discuss) No Objection
All of my comments are addressed. Thanks!