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

From: "Soliman, Hesham" <[email-masked]>
Date: Sat, 22 Apr 2006 09:10:23 -0700

>    Finally, this draft should not be inventing new packet formats for
 >    MIPv6.
 >    The purpose is to make sure that IKEv2/new IPsec specs can work
 >    with mipv6, not to introduce new features that we could 
 > have done with
 >    the old specs anyway but chose not to. 
 >    
 > => I agree but the problem is the 3775bis will not be available soon,
 > so following the advice of the area director the chairs decided to
 > include this in the IKEv2 document. In exchange I asked and got
 > this WGLC about this specific point, so persons (as you) who don't
 > agree can explain why.

=> I agree this is a discussion we should have and involve more
than 3 people. My reasons were mentioned in another email, I'm copying
it here:

 > its useful when you want to setup only one
 > tunnel IPsec SA with the home agent for sending
 > and receiving BU/BAck, MPS/MPA and HoTi/HoT.

=> I don't think it's a tradeoff that is worth the trouble. 
You get an additional header, more complexity in the implementation, 
more trouble classifying packets in the access, potential
interoperability
problems ...etc and the gain is one SA instead of 2. 

Again, I'm happy to discuss this, but I strongly think that
this draft is not the right place for this change. I believe
it was a mistake to remove the HAO in some cases (payload traffic)
in 3776. If anything is to be changed, we should put back the HAO.

and the tread continued:

 > one SA instead of four. you can end up with
 > one SA for BU/BAck, one for HoTi/HoT, one
 > for MPS/MPA and one for tunneling payload
 > traffic. you could send all this traffic
 > through one SA.

=> So I take you understand the other points I've raised in
addition to the number of SAs. I think we all know that we
wouldn't end up with 4 SAs if we used the HAO, so this statement
is not accurate.

I see no reason for using tunnel mode between two end 
nodes. HOTI/HOT were the only exceptions. 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....

Hesham

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

---

From: Francis Dupont <[email-masked]>
Date: Sun, 23 Apr 2006 00:08:52 +0200

=> IMHO the real argument is privacy even the tunnel all mode is
simpler from an IPsec point of view.

   You get an additional header,

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

   more complexity in the implementation, 

=> as I explained the complexity was already there.

   more trouble classifying packets in the access,

=> IMHO it is less trouble than more trouble.

   potential interoperability problems

=> a new option in the current interoperability problem, i.e., have
compatible policies on the MN and the HA, including for hidden things
like SA sharing.

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

   Again, I'm happy to discuss this, but I strongly think that
   this draft is not the right place for this change.

=> IMHO you should open another thread for this point.

   I believe
   
=> I don't fully understand your proposal (pointer/description?)

   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.

   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 
   
=> perhaps because you idea was not understood?
   
Regards
   
[email-masked]

PS: the discussion should be extended to the nemo WG too.

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 23 Apr 2006 15:09:33 -0700

> You get an additional header, more complexity in the implementation, 

it only simplifies things by having to deal with
only one tunnel SA.

> problems ...

there should no interop issues. perhaps you should
elaborate.

Vijay