Subject: summary of discussion was [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 24 Apr 2006 19:15:13 -0700

Folks, 

I'm sure following this discussion was difficult for a lot of people,
so here's a summary of what was discussed publicly and privately. 

My understanding from the answers to my comments is that the intention
of changing section 3 is to clarify something that is thought to be
already 
"implicitly" supported in the current specs. Other arguments for adding
this
new format included the privacy issue, VPN support and simplification or
reduction
of SAs. 

I think we disagree on whether the format in section 3 is new or simply 
a clarification of an existing format. I believe the BU format is
clearly
stated in section 11.7.1 in RFC 3775 and that the one in section 3
is a different format. I'm attaching the relevant part to
the end of this email.

I'm not against adding new things in general, we do that all the time. 
However, my objections are (not in order of importance):

- Defining a new format for the BU is outside the scope of this 
doc which deals with making sure that MIP6 and IPsec (ng) work together.

This does not involve defining new MIP6 messages. 

- The privacy argument is weak for several reasons. There are already
several approaches that address this in a more comprehensive manner.
Doing
things piecemeal will cause the overall solution to be heavier for no
gain.
Also, if we need to do something for privacy it should be done
separately
and a deeper discussion should take place. So why the rush?

- Simplfiying things: Actually, things would be much simpler if we don't
require a MIP6-IPsec API and K flags to detect what the MN can do. This 
means that doing everything in transport mode with the HAO *is* the
simpler
option here and will reduce the number of SAs and work perfectly fine
for the VPN 
case. Vijay already stated that this will require the implementations to
change, 
I agree, but so would tunnel mode for the BU. 

So here's what I'm suggesting: 

1. Revert to the old section 3 in the previous version. 

2. If the WG thinks that we need to define one mode for IPsec
between the MN and HA, then the sensible way to go here is to
use transport mode for all. If we decide that this is not needed
then we can keep things as they are. I'm fine with either case. 

Hesham

Excerpt from 11.7.1

o  The Home Registration (H) bit MUST be set in the Binding Update.

   o  The Acknowledge (A) bit MUST be set in the Binding Update.

   o  The packet MUST contain a Home Address destination option, giving
      the mobile node's home address for the binding.

   o  The care-of address for the binding MUST be used as the Source
      Address in the packet's IPv6 header, unless an Alternate Care-of
      Address mobility option is included in the Binding Update.  This
      option MUST be included in all home registrations, as the ESP
      protocol will not be able to protect care-of addresses in the IPv6
      header.  (Mobile IPv6 implementations that know they are using
      IPsec AH to protect a particular message might avoid this option.
      For brevity the usage of AH is not discussed in this document.)

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Apr 2006 22:19:40 -0700

> so here's a summary of what was discussed publicly and privately. 

unfortunately this isnt a summary. its how you
saw the discussion.

> "implicitly" supported in the current specs. 

more than "thought". we *know* it is implicitly
supported because we wrote up the text in a
specific way. moreover it is used.

> doc which deals with making sure that MIP6 and IPsec (ng) work together.

how to encapsulate a mip6 packet with an ESP
header is actually very much in scope of this
draft.

> This does not involve defining new MIP6 messages. 

we are not defining new MIP6 messages.

> and a deeper discussion should take place. So why the rush?

the privacy solutions have actually advanced
quite well. a tunnel BU is complementary to
these solutions. the work is progressing quite
well in mobopts and should make it to the MIP6
WG quite soon. the privacy problem statement
is already a MIP6 WG document. it was initially
written up in the mobopts group.
http://www.ietf.org/internet-drafts/draft-ietf-mip6-location-privacy-ps-01.txt 

I dont know what "rush" you are talking about.

> 1. Revert to the old section 3 in the previous version. 

you are asking for "status quo". I am afraid
thats not an option. reverting to old section
3 leaves the format for tunnel mode BU ambiguous.
thats what is being fixed here.

> use transport mode for all. 

please write it up and propose it to the WG.
I am fine with multiple ways of sending a BU.

Vijay