Re: Resolution of my discuss comments for draft-ietf-v6ops-nap-02.txt

[Jari Arkko <jari.arkko@piuha.net>]

Hi Tony,

>Jari Arkko wrote:
>  
>
>>>tone/language
>>>      
>>>
>>Much better indeed, but still a few terms that
>>you probably should remove (search for "marketing").
>>    
>>
>
>Despite the distaste for the term, people don't evaluate the technical
>trade-offs, they buy what they have been told will solve their problem. That
>is 'marketing'. Earlier versions were a little heavy on the point, but there
>are only 2 references in the intro and one in the security issues at this
>point, so I believe the document actually carries the appropriate tone about
>why its existence is even necessary.  
>  
>
I re-read the specific examples. Lets go through them one by one.

   Indeed, product marketing departments have
   effectively driven a perception that some connectivity and security
   concerns can only be solved by using a NAT device, without any
   mention of the negative impacts on applications.  This is amplified
   through the widespread sharing of vendor best practice documents and
   sample configurations that do not differentiate the translation
   function of address expansion from the state function of limiting
   connectivity.

I wholeheartedly agree with the second sentence. But the first sentence
focuses on the role of the product marketing whereas in reality I believe
the situation was more complicated. The desires of equipment vendors
got mixed with the desires of the service providers, and with real-world
issues with addresses etc. How about this: "Indeed, it is often claimed
that some connectivity and ..."

   IPv4 NAT was not developed as a security mechanism.  Despite
   marketing messages to the contrary it is not a security mechanism,
   and hence it will offer some security holes while many people assume
   their network is secure due to the usage of NAT.

This seems fine.

   Product marketing departments have widely
   sold IPv4 NAT as a security tool and suppliers have been implementing
   address translation functionality in their firewalls, though the
   misleading nature of those claims has been previously documented in
   [2] and [4].

I don't have a strong opinion on this, but I would use "NAT has been
sold as a security tool ..."

>>...
>>     The downside with a Mobile IPv6 based solution is that it requires
>>     a home agent in the network, the configuration of a security
>>     association for each mobile node, and consumes some amount of
>>     bandwidth for tunnel overhead. 
>>    
>>
>
>Replaced existing with this.
>  
>
Ok.

>>A random, dynamic assignment
>>     of home addresses without manual intervention also requires
>>     support for IKEv2-based extension to Mobile IPv6
>>     [I-D.ietf-mip6-ikev2-ipsec].
>>    
>>
>
>Is this a level of detail beyond the scope of the document? 
>  
>
Good question. We could also use text that has less details, e.g., "A
dynamic
assignment of home addresses requires extensions that are currently
being defined in the IETF."

>>>4.2 -2 does not oversell IPsec, it simply states the real situation.
>>>
>>>
>>>      
>>>
>>I'm not going to hold your document based on the -03 text, but
>>I would still suggest the following edit:
>>
>>       While IPsec might be available in IPv4
>>       implementations and works the same way, deployment in NAT
>>       environments either breaks the protocol or requires complex
>>       helper services with limited functionality or efficiency.
>>=>
>>       While IPsec is commonly available in IPv4 implementations
>>       and can support NATs, NAT support has limitations and
>>       does not work in all situations. In addition, the use of IPsec
>>       with NATs consumes extra bandwidth for UDP encapsulation
>>       and keepalive overhead.
>>    
>>
>
>You appear to be assuming desktop/server OS's. Many/most cell-phone/pda OS's
>and virtually-none of the embedded appliance implementations include IPsec
>for IPv4. Even when they do they don't include the nat traversal pieces.I
>did add the comment about the helper services not working in all situations.
>  
>
It is true that such devices are less likely to have IPsec, or
other advanced features. (Features tend to be added to
devices when there is a clear, specific function they enable.
Perhaps more so than IETF mandates, even for IPv6.
For instance, corporate VPN access has been a driver for
IPsec inclusion in higher-end cell phone / pda devices.)

Would you be happier with the text with s/IPv4/some IPv4/?

--Jari