Last Call Review of draft-arkko-dual-stack-extra-lite-
review-arkko-dual-stack-extra-lite-secdir-lc-kent-2011-02-01-00

Request Review of draft-arkko-dual-stack-extra-lite
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-02-15
Requested 2011-01-17
Authors Jari Arkko, Lars Eggert, Mark Townsley
Draft last updated 2011-02-01
Completed reviews Secdir Last Call review of -?? by Stephen Kent
Tsvdir Last Call review of -?? by Martin Stiemerling
Assignment Reviewer Stephen Kent
State Completed
Review review-arkko-dual-stack-extra-lite-secdir-lc-kent-2011-02-01
Review completed: 2011-02-01

Review
review-arkko-dual-stack-extra-lite-secdir-lc-kent-2011-02-01

Title: 

review of
draft-arkko-dual-stack-extra-lite-03




I 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 is a very brief (8-page) document. It defines how to employ
address translation (NAT) to serve a large (> 2^24) user population
without making use of a large private address space. Thus the focus
here is a bit different from the usual NAT context, where one uses a
large-enough private address space behind a NAT, and maps that space
into a smaller (typically IPV4) address space on the other side of a
NAT.





The authors review several other approaches to dealing with the
problem, as a prelude to presenting the proposed solution. The
solution put forth here is applicable to nets where each endpoint has
a point-to-point link to a NAT (vs. a broadcast net). The authors note
that if tunneling is already being used to connect endpoints to a
gateway/NAT, this technique also is applicable. In either case the NAT
maintains a map between the overlapping private address spaces and the
public space by associating a network interface ID (as well as the
private IP address) with each endpoint.





The authors recommend employing their solution for dealing with the
IPv4 addresses that need to be associated with endpoints in the dual
stack [RFC 4213] deployment model for IPv6. They also note that their
proposal could be used in another IPv6 deployment model
[I-D.ietf-behave-v6v4-xlate-stateful], but that it probably is not
necessary there, because of the abundance of IPv6 address space.





The security considerations section is but one sentence: "This
practices outlined in this document do not affect the security
properties of address translation." I think this needs to be
expanded upon

 :

. The authors should cite
at least one RFC that deals with NAT and has sustentative security
considerations section. If they can't find a suitable RFC (2993 is the
obvious candidate, but it is outdated in several of its references and
comments) then they at least describe why they believe that this
proposal introduces no new security implications.