Re: [Dime] draft-ietf-dime-nat-control-01.txt

["Shwetha Bhandari (shwethab)" <shwethab at cisco.com>]

Hi Melinda,

Thanks for reviewing our draft! 

We have reviewed other protocols in this space in a separate draft, and
this includes MIDCOM and SIMCO:

http://tools.ietf.org/html/draft-brockners-nat-control-protocols-review-
00 

We will rework the security consideration section of our draft. We have
refered in Section 11 and Section 5.1 of the draft to use Diameter over
IPSec for mutually authenticating Diameter NAT control manager and
agent. Adding dime group for suggestions on how we can update the draft
to address your concern, as there are other application (e.g. Diameter
QoS) that would have similar security considerations.

Thanks,
Shwetha

-----Original Message-----
From: Melinda Shore [mailto:shore at arsc.edu] 
Sent: Tuesday, October 27, 2009 3:48 AM
To: Frank Brockners (fbrockne); Shwetha Bhandari (shwethab);
vaneeta at mavenir.com; vfajardo at research.telcordia.com
Subject: draft-ietf-dime-nat-control-01.txt

Hi, all:

I enjoyed reading the draft.  Because you didn't reference them it
wasn't clear to me whether or not you were aware of prior work in this
area, including the midcom protocol produced by the midcom working group
a few years back (see RFCs 3303, 3304, 4097, 5189, and 5190), or the
SIMCO protocol (RFC 4540).
I also did a NAT/firewall application over DIAMETER while I was at Cisco
a number of years ago but the midcom working group chose SNMP.  I think
DIAMETER is a fine choice although it may be easier to use a protocol
that's already gone through the IETF process and been published as an
RFC.

Anyway, without going into protocol specifics I think the security
considerations section needs to be beefed up quite a bit.  In
particular, while it's most typically the case that a client will
authenticate to a server, for NAT control it's imperative that the
server (NAT) authenticate itself to the client.
The reason is that a fairly simple attack against a NAT control protocol
is to inject a bogus response to a mapping request, which allows the
attacker to redirect a data stream when the address is shared using a
signaling mechanism (VoIP - I note that you reference the TISPAN work
from ETSI).  A possible mitigation is to authenticate the data stream in
the application, but I do think that the possibility of server
authentication should be included for deployments with stricter security
requirements.

Melinda Shore
Arctic Region Supercomputer Center
shore at arsc.edu