Re: [Dime] FW: SECDIR review of draft-ietf-dime-nat-control-07

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

FYI. I've just posted a revision (draft-ietf-dime-nat-control-08), which
now includes an extended security section - closely following Matt's
comments (Matt, thanks again for the very detailed comments).

Regards, Frank

> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> Of
> > Romascanu, Dan (Dan)
> > Sent: Wednesday, March 09, 2011 5:51 PM
> > To: [e-mail]
> > Subject: [Dime] FW: SECDIR review of draft-ietf-dime-nat-control-07
> >
> >
> >
> >
> > -----Original Message-----
> > From: Matt Lepinski [mailto:[e-mail]]
> > Sent: Wednesday, March 09, 2011 3:33 PM
> > To: [e-mail]; [e-mail];
> > [e-mail]
> > Subject: SECDIR review of draft-ietf-dime-nat-control-07
> >
> > I have reviewed this document as part of the security directorate's
> > ongoing effort to review all IETF documents being processed by the
> > IESG.
> > These comments were written primarily for the benefit of the
security
> > area directors. Document editors and WG chairs should treat these
> > comments just like any other last call comments.
> >
> > This document defines a Diameter application whereby a Diameter NAT
> > Control Application (DNCA) server (either a AAA server or a Network
> > Access Server) can control a DNCA client (either a NAT or NAPT
> device).
> > For example, the DNCA server can determine the number of port
> bindings
> > available to a given host, cause the allocation of particular NAT
> > bindings, define the external address pool used for by the NAT
> device,
> > or generate reports used for accounting purposes.
> >
> > The principle security concern is that an unauthorized (or
> > unauthenticated) DNCA server could effect a denial of service of
> attack
> > on any or all hosts using a NAT/NAPT device in several ways. (E.g.,
> an
> > unauthorized server could exhaust resources in the NAPT device, set
> > maximum bindings to zero for all hosts, provide a set of external
> > addresses that are in use elsewhere in the network, etc.) An
> additional
> > concern is that an unauthenticated DNCA client could provide
> incorrect
> > reporting data to the DNCA server to prevent correct accounting
> within
> > the system. Therefore, the NAT control application requires mutual
> > authentication, authorization of the DNCA server, and integrity
> > protection of the Diameter messages in the DNCA interaction.
> > Additionally, the application may require confidentiality depending
> on
> > the deployment scenario and, particularly, how authorization is
> > accomplished.
> >
> > The Security Considerations section of the document claims that
> > security
> > considerations are essentially the same as in the Diameter QoS (RFC
> > 5866). I agree with the authors that the security concerns for
> Diameter
> > NAT Control are very similar to the security concerns for Diameter
> QoS,
> > but I think the additional layer of indirection is not helpful to
the
> > reader. (In particular, the NAT Control Application has no
> dependencies
> > on the Diameter QoS document. Therefore it is reasonable to believe
> > that
> > an implementer of Diameter NAT Control may not be familiar with the
> > Diameter QoS document.) I would recommend that the authors add
> > additional text explaining why mutual authentication, server
> > authorization, and message integrity are required (copying a bit of
> > text
> > from RFC 5866 may be appropriate). Then I would recommend that the
> > authors cite the Diameter specification (RFC 3588) for a discussion
> of
> > how IPsec or TLS can be used to obtain these security properties.
(To
> > me, this seems preferable to sending a reader to RFC 5866 for
> > discussion
> > of required security properties, which in turn sends the reader to
> RFC
> > 3588 for an information on the use of IPsec or TLS to achieve these
> > properties.)
> >
> > Finally, the end of the security considerations section claims that
> > "Authorization between DNCA Agent and
> >     DNCA Manager is beyond the scope of this document". I understand
> > that the authors do not want to mandate a particular mechanism for
> > making an authorization decision. That being said, providing some
> > guidance as to how a DNCA client would determine if a DNCA server
> were
> > authorized to issue NAT control commands. I imagine in practice that
> > the
> > way authorization is accomplished is that the NAT/NAPT device stores
> a
> > local authorization policy. (E.g., the device stores a list of
server
> > identities that authorized, and then once the server has been
> > authenticated its identity can be checked against the list). At the
> > very
> > least having text analogous to first paragraph of RFC 5866 Section
11
> > would be helpful (RFC 5866 says the device making the authorization
> > decision needs to have sufficient information to make this decision
> and
> > then provides examples of where this information would come from.)
> >
> > - Matt Lepinski
> >
> >
> >
> > _______________________________________________
> > DiME mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dime