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

From: Jari Arkko <[email-masked]>
Date: Sun, 23 Jul 2006 22:42:37 +0300

Hi Tony,

I am looking at -03 and the diffs that you sent. The new
version is much better. More discussion of my DISCUSS
issues below:

> tone/language

Much better indeed, but still a few terms that
you probably should remove (search for "marketing").
Maybe also s/mangling/changing/g.

>2.2 has already been reworked.
>  
>
The new text is better, thanks.

>3.4 does not oversell if you understand how MIPv6 really works. 
>  
>
The text in Section 4.4 of -03 is much better. I'm going to suggest
an additional small change, but first I'd like to explain the concern
that I had.

Draft -02 talked about random address assignment and Mobile IPv6.
However, as you probably know the security of Mobile IPv6 relies
on the home agent knowing which mobile node is authorized to
use which home address, and the existence of a pre-configured
security association between the mobile node and the home agent.
Mobile IPv6 as defined in RFC 3775 did not enable random or even
dynamic home address assignment. We are changing that now as
a part of ongoing work in MIP6 WG (currently a draft in AD Review
stage). However, even after this there is an expectation of an
existing security association per mobile node.

The additional text change that I would suggest is:

      The   
      downsides of using the MIPv6 tunneling method is that it makes   
      usage of middleware like a Home Agent (HA) and consumes slightly   
      more bandwidth for the tunnel overhead.

=>

     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. 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].

>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.

>4.3 has additional text, though this is one where the IESG has lost the
>context of this being wrt a nat deployment. 
>  
>
The new text in -03 works for me.

>4.7 the comments here are just wrong because it already did cover the points
>and there was already a forward reference, it just didn't specify 6.4 as the
>section number.
>  
>
Ah, I missed the reference, sorry. Section 6.4 looks reasonable
to me.

The one remaining thing that I would suggest you add here is
a warning about the issues in multihoming and ingress filtering.
If I read Section 4.7, I get the feeling that multiple prefixes and
multiple ISPs works fine today, which may not be exactly correct,
see e.g. draft-huitema-shim6-ingress-filtering. Do not add a lot
of text, just mention that there are issues in some cases in the
multiple-ISP model.

>I did not buy all of Margaret's personal views though clarifications were
>added. 
>I did not expand on renumbering as Thomas requested. It is not clear to me
>what he wants beyond referencing rfc 4192. The second paragraph of 2.5 could
>be expanded, but that is not the focus of the section. The second paragraph
>of 2.7 could be expanded, but would seem to loose context. It sounds like he
>wants a statement like 'renumbering is hard in IPv4' as justification for
>nat.
>  
>
I need to read the thread on the list between you and Margaret and others
to see if we've converged in the WG about this. I will comment Margaret's
and Thomas' issues and their resolution on the list separately.

--Jari

---

From: Fred Baker <[email-masked]>
Date: Mon, 24 Jul 2006 17:48:32 -0700

for the record, this is only true of transport mode. tunnel mode  
works just fine in IPv4, and I have every reason to believe that it  
will continue to do so in IPv6. I use tunnel mode a lot, including at  
IETF meetings.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 25 Jul 2006 11:06:09 +0300

Fred,

Are you suggesting changing the text below in some
manner? It seems that this point is still covered under
the works in some cases/does not work in all cases
language.

(By the way, it is my belief that IPsec NAT traversal UDP
encapsulation is used commonly even for tunnel mode VPN
connections, for various reasons. The primary reason is
that when there are multiple clients behind the same NAT,
the NAT is unable to determine where a particular return
packet should go to -- the SPIs are different in different
directions and their negotiation is encrypted so the NAT
can't peek into the packet to find out. You can guess, but
there is no guarantee that this always works.)

--Jari

Fred Baker wrote:

> for the record, this is only true of transport mode. tunnel mode works
> just fine in IPv4, and I have every reason to believe that it will
> continue to do so in IPv6. I use tunnel mode a lot, including at IETF
> meetings.
>

---

From: Fred Baker <[email-masked]>
Date: Tue, 25 Jul 2006 05:51:31 -0700

I think the new text is better than the old, but the caveat isn't a  
NAT caveat, it is an IPSEC caveat. Yes, while IPSEC's tunnel mode  
could be implemented using an IP header and an IPSEC header (HAIPE,  
for example, which is an encryptor and *not* a NAT), it is common to  
include a UDP or TCP header as well. That is an *IPSEC* issue. People  
that use tunnel mode do so because they have chosen to hide their  
topology. When they convert to IPv6 (HAIPE version 3.0 for example),  
encryptors will continue to use tunnel mode for the same reason, and  
will do so inside IPv6.

I would suggest that this document reserve its negative commentary  
for NATs, not scattershot for other protocols, and that it not  
attempt to deprecate tools that people will be continuing to use. The  
purpose of the note was to demonstrate how to best achieve things- 
people-use-NATs-for using IPv6 without using NATs. I'd suggest it  
stick to that.

On Jul 25, 2006, at 1:06 AM, Jari Arkko wrote:
>> works

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Jul 2006 11:42:21 -0700

> 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.  

> ...
>      bandwidth for tunnel overhead. 

Replaced existing with this.

> A random, dynamic assignment

Is this a level of detail beyond the scope of the document? 

>        with NATs consumes extra bandwidth for UDP encapsulation

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.

> ...

Does this work for you:
Additional considerations are being documented as multihoming work evolves
xref  ---  draft-bagnulo-shim6-ingress-filtering-00.txt

Tony

---

From: Fred Baker <[email-masked]>
Date: Wed, 26 Jul 2006 17:30:29 -0700

> xref  ---  draft-bagnulo-shim6-ingress-filtering-00.txt

I eonfder how many of these are discussed in RFC 3704?

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 27 Jul 2006 14:24:29 -0700

The ID is essentially more detail on how to work around the ingress filters
with tunnels and source routing, but the outcome is already covered in 3704.

Tony

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]]
> Sent: Wednesday, July 26, 2006 5:30 PM
> To: Tony Hain
> Cc: 'Jari Arkko'; [email-masked]
> Subject: Re: Resolution of my discuss comments for draft-ietf-v6ops-nap-
> 02.txt
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Sun, 30 Jul 2006 19:28:45 +0300

I would be fine with referencing 3704. But the draft that
I referenced was merely an example. Perhaps it would
be best if you adding a little bit detail to the work-in-progress
warning that you already have in Section 4.7. For instance,

   Multihoming and renumbering remain technically challenging with IPv6
   (see the Gap Analysis below).  However, IPv6 was designed to allow
   sites and hosts to run with several simultaneous CIDR allocated
   prefixes, and thus with several simultaneous ISPs.  An address
   selection mechanism [10] is specified so that hosts will behave
   consistently when several addresses are simultaneously valid.  The
   fundamental difficulty that IPv4 has in regard to multiple addresses
   therefore does not apply to IPv6.  IPv6 sites can and do run today
   with multiple ISPs active, and the processes for adding, removing,
   and renumbering active prefixes at a site have been documented in
   [13] and [20].

=>

   IPv6 was designed to allow
   sites and hosts to run with several simultaneous CIDR allocated
   prefixes, and thus with several simultaneous ISPs.  An address
   selection mechanism [10] is specified so that hosts will behave
   consistently when several addresses are simultaneously valid.  The
   fundamental difficulty that IPv4 has in regard to multiple addresses
   therefore does not apply to IPv6.  IPv6 sites can and do run today
   with multiple ISPs active, and the processes for adding, removing,
   and renumbering active prefixes at a site have been documented in
   [13] and [20]. However, multihoming and renumbering remain technically
   challenging even with IPv6 with regards to, for instance, session
   continuity across multihoming events or interactions with
   ingress filtering (but see the Gap Analysis below).

Or words to that effect. You might considering moving some
of the discussion to Section 6.4, for intance.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 30 Jul 2006 22:34:42 +0300

Hi Tony,

>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 ..."

>Replaced existing with this.
Ok.

>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."

>for IPv4. Even when they do they don't include the nat traversal pieces.I
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

---

From: "Eric Klein" <[email-masked]>
Date: Mon, 31 Jul 2006 11:23:06 +0300

> that some connectivity and ..."

I would think that changing the pharase "product marketing" to "hardware 
companies" without pointing at marketing as the speciffic group responsible. 
This should maintain the message while doing away with the word marketing 
that has been causing so much discussion.

> sold as a security tool ..."

I can live with this suggestion.

<snip>

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

I aticiapte that in the near future the IP excryption options will cause 
problems as DPI products (and the associtated service featuers like protocol 
based QoS are demanded) and enforcable wire tapping aer mandated then the 
concepts of IPSec in mobile will not be such a widley used feature.
- Eric