Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt

From: "Soliman, Hesham" <[email-masked]>
Date: Sun, 23 Apr 2006 11:25:51 -0700

>    
 >    => I don't think it's a tradeoff that is worth the trouble. 
 > 
 > => IMHO the real argument is privacy even the tunnel all mode is
 > simpler from an IPsec point of view.

=> If the idea is to hide the HoA then we should devise a solution
for this in a seperate doc, this is a completely separate topic. As 
you might remember, Claude had an idea for generating a random HoA
a few years ago. A privacy draft would be fine, but we certainly haven't
discussed/agreed on the privacy space. So we shouldn't be putting a
solution
when others were proposed earlier. 

 > 
 >    You get an additional header,
 > 
 > => only for packets previously protected by a transport mode, i.e.,
 > a very low amount of traffic.

=> Yes but we're talking about the BU, this is what the draft changed. 
It might not be as frequent as data but adding another header during 
the handover time is most unhelpful. 

 > 
 >    more complexity in the implementation, 
 > 
 > => as I explained the complexity was already there.

=> The complexity was *added* in 3776 unnecessarily. If we want 
to reopen this area then we should go back to using transport
mode with the HAO and remove all this complexity of requiring 
MIP6-IPsec interactions which took people years to support! 
I never saw a good reason for this troublesome design.

 >    and the gain is one SA instead of 2. 
 >    
 > => the gain is privacy (and full IPsec VPN compatibility, if you
 > believe it is a gain).

=> I don't believe this is the best way of doing privacy and I certainly
don't think it belongs to this draft. 

 >    I see no reason for using tunnel mode between two end nodes.
 > 
 > => here it is to make no difference between MN-CN and MN-HA.

=> I don't understand this statement or the one below. 

 >    HOTI/HOT were the only exceptions.
 > 
 > => there are not exceptions, there are the only case where mobility
 > requires this kind of protection (note that all words are important).

 > 
 >    I think removing 
 >    the HAO was a mistake from the beginning and I said it numerous
 >    times. The result of the mistake are very clear. If we want to 
 >    make things simpler we should just use the HAO. 
 >    But everytime I bring this up (including in Dallas) I get 
 > "silence" and 
 >    no one explains why we can't rely on transport mode with 
 > the HAO....
 >    
 > => perhaps because you idea was not understood?

=> I don't know if it was or wasn't because I never received an
answer...

Hesham

 >    
 > Regards
 >    
 > [email-masked]
 > 
 > PS: the discussion should be extended to the nemo WG too.
 > 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Francis Dupont <[email-masked]>
Date: Sun, 23 Apr 2006 23:26:30 +0200

a few years ago.

=> as one of the authors of the I-D I really remember (:-). But the
issue is a bit different here because between the MN and the HA the HoA
is visible only in BU/BA. This has some advantages (i.e., it was not
designed by accident) but doesn't fit well with privacy.

   A privacy draft would be fine, but we certainly haven't
   discussed/agreed on the privacy space. So we shouldn't be putting a
   solution when others were proposed earlier. 
   
=> the tunnel all idea is not new so your argument is more procedural
than technical.

    > => as I explained the complexity was already there.
   
   => The complexity was *added* in 3776 unnecessarily.

=> I disagree, the complexity is from the struture of IPsec policies
and was not added in 3776. To put some MUST to remove all freedom
would give complete compatibility for an empty set of implementations...

   If we want 
   mode with the HAO

=> I don't understand how the transport mode can be used between
the MN and CNs in all cases. Can you explain your idea?

   and remove all this complexity of requiring 
   MIP6-IPsec interactions which took people years to support! 

=> the way to support them has been known since some years so
the issue is not there.

=> which design?

   
=> the traffic terminating at the HA or going through the HA are dealt
the same way.

Regards