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

From: "Soliman, Hesham" <[email-masked]>
Date: Sun, 23 Apr 2006 14:41:41 -0700

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

=> The whole point of the draft I'm referring to was to create a pseudo
HoA to be included after the first BU. So the issue is not any different
from the one attempted in this draft. Having this discussion shows that
we don't even agree on a privacy solution yet, so why shove it into
this draft??

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

=> No it's not, I've already mentioned several technical reasons
for this. And yes there is a procedural reason, but that's not
the only one. 

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

=> I'm talking about removing the HAO option for tunneled traffic to
the HA and using tunnel mode. Of course this was added in 3776. 

 >    If we want 
 >    to reopen this area then we should go back to using transport
 >    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?

=> Where did I claim that we should use transport mode to the CN? 
I've been talking about the BU in every email...This *is* what the new
section 3 in the draft modifies. 
Transport mode is used for the BU now and MPD now. It can also be used 
for all tunneled traffic to the HA (to protect payload traffic) if we
use
the HAO. 

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

=> Know != supported in implementations.

Hesham

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

---

From: Francis Dupont <[email-masked]>
Date: Mon, 24 Apr 2006 00:11:41 +0200

In your previous mail you wrote:

=> the transport mode is end to end, so it can't be used from the
MN to the CN using the HA both as a router and the end of the SAs.

=> you didn't explain your idea.

   use the HAO.

=> you want to use a transport mode with a HAO for the tunneled traffic,
i.e.:
    IPv6 header (src=CoA, dst=HA)
    HAO (with HoA)
    ESP header
    IPv6 header (src=HoA, dst=*)
    Payload
Is your proposal?

   
=> yes but in this case the issue is not technical.
   
Regards

[email-masked]

---

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

> we don't even agree on a privacy solution yet, so why shove it into

Hesham,

you are mixing up things. you should look up the
discussion on the mobopts WG. it is working on
a solution for generating temporary HoAs and use
them instead of the actual HoA. but this requires
some support on the CN too. the CN needs to know
how to deal with the temporary HoA.

the "tunnel all" mode is used to hide the HoA
from the access network. this requires no support
on the CN. the "tunnel all" mode is already there.
it is *not* a new solution.

Vijay