behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On Behalf Of Dave
Sent: Friday, August 05, 2011 2:13 AM
To: draft-ietf-dime-nat-control <at> tools.ietf.org;
dime-chairs <at> tools.ietf.org
Cc: David Harrington; behave <at> ietf.org; Romascanu, Dan (Dan)
Subject: [BEHAVE] My review of draft-ietf-dime-nat-control-09
My review of this draft is at
or (same content)
High level questions:
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)?
…..FB: We clarified that DNCA applies to n:m
scenarios, with n NAT-Controllers and m NAT-devices. Section 3.3 now discusses
3.3. Deployment Scenarios For DNCA
DNCA can be deployed in different ways. DNCA
with "n" NAT-controllers and
"m" NAT-devices, with n and m equal to
or greater than 1. For DNCA, the session
representing a particular
endpoint is atomic. Any deployment MUST
ensure that for every given
endpoint only a single NAT-controller and only a
are active at any point in time. This is to
ensure that NAT-devices
controlled by multiple NAT-controllers do not
control requests for a particular endpoint, or
would be unclear which
NAT-controller to send accounting information to.
seems to be a MAY. Why not a SHOULD or a MUST? Using
only a MAY warrants an explanation.
Agreed. And we refer to security as a SHOULD throughout the document.
no mention of DoS attack by filling up logs. Is that a concern?
...FB: It could be a concern, if the logging infrastructure is
not designed with potential DoS attacks in mind. We've updated the security
section to reflect this (see section 12):
of any of the
two DNCA Diameter peers to provide the required
should be subject to logging. The corresponding logging
of the operator SHOULD be built in a way that it can
potential denial of service attacks resulting from large
amounts of logging
events. This could include proper dimensioning of
infrastructure combined with policing the maximum amount
events accepted by the logging system to a threshold which
the system is
known to be able to handle.
Rest is mostly editorial nits.
…FB: Thanks for catching
all these nits. Really helpful (and hopefully we reflected all of them in revision
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.