Subject: Re: [MEXT] FW: New Version Notification for draft-patil-mext-mip6issueswithipsec-00

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 17 Nov 2008 11:39:39 -0600

Hi Raj,

I went through the draft and have following comments.

   (3)  A MIP6 home agent is one end of the IPsec SA in a many-to-one
         relationship.  A MIP6 HA may support a very large of mobile
         nodes which could number in the hundreds of thousands to
         millions.  The ability to terminate a large number of IPsec SAs
         (millions) requires signifiant hardware and platform  
capability.
         The cost issues of such an HA are detrimental and hence act  
as a
         barrier to deployment.

I partially agree, but the protection of data traffic must be mandated  
in some scenarios.
Therefore, I would say using IPsec for protecting signaling might be  
problematic, but not for data packets.

   (4)  The implementation complexity of Mobile IPv6 is greatly
         increased because of the interaction with IPsec and IKEv2.  A
         standalone MIP6 protocol is easier to implement and deploy  
(such
         as MIP4 [RFC3344]).  The complexity of the protocol
         implementation is even more so in the case of [DSMIP6].

True, IPsec/IKE are painful part when implementing Mobile IPv6.
There is another reason that is supporting the feature of returning  
home.
We need a lot of special codes for returning home (including SAD/SPD  
parts).

    (9)  The way that the IPsec code sits in the usual kernel, and the
         access mechanisms for the SA database, are not very convenient
         for use by straightforward implementations of Mobile IPv6.
         Unusual calling sequences and parameter passing seems to be
         required on many platforms.

I repeated this several time, but we should have informational RFC  
something like
http://tools.ietf.org/html/draft-sugimoto-mip6-pfkey-migrate-04
This is very useful document for implementators.

I have another concern.
Whenever MN moves, MN needs IKE signaling if the feature of K-bit is  
not supported.
We have to consider the movement latency including IKE/MIP signaling  
exchange.
We do not optimize the IKE part. As a result, MN may not do fast  
handover...

thanks,
ryuji

On 2008/10/27, at 12:27, Basavaraj Patil wrote:

>
> FYI,
>
> ------ Forwarded Message
> From: ext IETF I-D Submission Tool <[email-masked]>
> Date: Mon, 27 Oct 2008 09:55:13 -0700 (PDT)
> To: Basavaraj Patil <[email-masked]>
> Cc: Charles Perkins <[email-masked]>, <[email-masked] 
> >
> Subject: New Version Notification for
> draft-patil-mext-mip6issueswithipsec-00
>
>
> A new version of I-D, draft-patil-mext-mip6issueswithipsec-00.txt  
> has been
> successfuly submitted by Basavaraj Patil and posted to the IETF  
> repository.
>
> Filename:  draft-patil-mext-mip6issueswithipsec
> Revision:  00
> Title:   Issues related to the design choice of IPsec for Mobile IPv6
> security
> Creation_date:  2008-10-27
> WG ID:   Independent Submission
> Number_of_pages: 15
>
> Abstract:
> Mobile IPv6 as specified in RFC3775 relies on IPsec for security.  An
> IPsec SA between the mobile node and the home agent provides security
> for the mobility signaling.  Use of IPsec for securing the data
> traffic between the mobile node and home agent is optional.  This
> document analyses the implications of the design decision to mandate
> IPsec as the default security protocol for Mobile IPv6 and recommends
> revisiting this decision in view of the experience gained from
> implementation and adoption in other standards bodies.
>
>
>
> The IETF Secretariat.
>
>
>
> ------ End of Forwarded Message
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 17 Nov 2008 11:39:38 -0800

Hi,

> This is very useful document for implementators.

Linux 2.6.28 will be fully compliant with a followup document I wrote
(SADB_X_EXT_PACKET part removed and replaced by KMADDRESS extension, a
more simple and efficient mechanism). Those changes have been merged
mainline:

http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00

I am currently handling integration of  associated patches in racoon
(for MIGRATE/KMADDRESS support). I also have interactions w/ people from
strongSwan project which are currently implementing what is specified in
my draft for Charon, the IKEv2 daemon. 

Patches for UMIP (will see that w/ Sugimoto-san) are also
available. Information is available on http://natisbad.org/MIPv6/

Comments appreciated if you have some time to review those pages and the
draft.

> We do not optimize the IKE part. As a result, MN may not do fast

When using IKE, an *unmodified* IKE daemon is not able to negotiate the
initial transport mode SA so K-bit does not make sense in the end. You
need to have a MIPv6-modified IKE implementation to bootstrap. Please,
take a look at previous draft. I have already raised the issue
(Sebastien Decugis has even written a draft on the topic.)

Cheers,

a+

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 17 Nov 2008 14:16:25 -0600

Hi

> Comments appreciated if you have some time to review those pages and  

good to know there are progresses on the spec and impl.

Shinta sent us a patch of PF_KEY modification for SHISA (BSD-MIP  
implementation) a long time ago.
I don't remember if we merge the patch or not.. Keiichi may answer this.

> (Sebastien Decugis has even written a draft on the topic.)

I personally don't care if IKE is modified or not for MIP.
My personal comment is that "it's better to mandate K-bit always set  
to 1."

regards,
ryuji

regards,
ryuji

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 17 Nov 2008 12:50:27 -0800

> I don't remember if we merge the patch or not.. Keiichi may answer this.

ack.

> I personally don't care if IKE is modified or not for MIP.

It just needs to. And this is required to have things working.

> My personal comment is that "it's better to mandate K-bit always set

a big +1

a+