From:
behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On Behalf Of Dave
Thaler
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
http://research.microsoft.com/en-us/um/people/dthaler/draft-ietf-dime-nat-control-09.pdf
or (same content)
http://research.microsoft.com/en-us/um/people/dthaler/draft-ietf-dime-nat-control-09.docx
High level questions:
1) The
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
this:
3.3. Deployment Scenarios For DNCA
DNCA can be deployed in different ways. DNCA
supports deployments
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
single NAT-device
are active at any point in time. This is to
ensure that NAT-devices
controlled by multiple NAT-controllers do not
receive conflicting
control requests for a particular endpoint, or
would be unclear which
NAT-controller to send accounting information to.
2) Security
seems to be a MAY. Why not a SHOULD or a MUST? Using
only a MAY warrants an explanation.
…FB:
Agreed. And we refer to security as a SHOULD throughout the document.
3) There’s
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):
[..] Failing
of any of the
two DNCA Diameter peers to provide the required
credentials
should be subject to logging. The corresponding logging
infrastructure
of the operator SHOULD be built in a way that it can
mitigate
potential denial of service attacks resulting from large
amounts of logging
events. This could include proper dimensioning of
the logging
infrastructure combined with policing the maximum amount
of logging
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
-11)
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.
Regards, Frank
-Dave
RSS Feed