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

[Ryuji Wakikawa <ryuji.wakikawa at gmail.com>]

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 <idsubmission at ietf.org>
> Date: Mon, 27 Oct 2008 09:55:13 -0700 (PDT)
> To: Basavaraj Patil <basavaraj.patil at nokia.com>
> Cc: Charles Perkins <charliep at wichorus.com>, <Hannes.Tschofenig at gmx.net 
> >
> 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
> MEXT at ietf.org
> https://www.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext