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

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 21 Apr 2006 13:25:49 -0700

> > => This is not relevant to my statement, I'm referring 
 > > to the MIPv6 specs 3775/6. Transport mode in general is
 > > needed for HOTI/HOT, 
 > 
 > I guess you meant tunnel mode.

=> yes.

 > 
 > > it's useless when the sender is protecting
 > > packets for the ultimate receiver with IPsec. 
 > 
 > 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.

 > 
 > > This is what
 > > transport mode is for!
 > 
 > disagree. many times the mobile node is unable
 > to setup transport mode SA with the CN.

=> ?? first of all we're talking about the BU to the HA. 
But why would tunnel mode be any harder with a CN?

 > 
 > > Mobopts is not part of IETF and has no bearing 
 > > on this discussion. 
 > 
 > the idea behind Mobopts is that the initial work
 > gets done there and then the solutions are
 > eventually standardized in the working groups in
 > the IETF. some examples.
 > draft-arkko-mipshop-cga-cba-03.txt,
 > draft-kempf-mobopts-handover-key-01.txt.

=> Honestly, I understand the ideas here but I strongly disagree
with this and I strongly disagree with adding it (if it's added 
at all) to this draft. If this is to be done at all, it should be
done in a different context. This draft has to be limited to its
original intention. 

 > in previous discussions it was decided that this
 > draft can update RFC 3775 and RFC 3776 if required.

=> I don't agree with that. Please point me to those emails
that included these decisions. 

Hesham

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 21 Apr 2006 14:00:59 -0700

> problems ...etc and the gain is one SA instead of 2. 

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.

> => ?? first of all we're talking about the BU to the HA. 

ok. I thought you were talking about the
HoTi.

> But why would tunnel mode be any harder with a CN?

we are not doing tunnel mode with the CN,
with the HA.

> done in a different context. This draft has to be limited to its

your objection is noted.

Vijay