[secdir] review of draft-arkko-dual-stack-extra-lite-03

[Stephen Kent <[e-mail]>]

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.