Subject: Re: [MEXT] [rfc3775] Application using the care-of address

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 08 Jul 2008 10:31:06 -0700

Hello folks,

It seems to me that socket handling by IKE versus
availability of the Care-of Address from MIPv6 is
out of scope for rfc3775bis.  I've created a new issue
for Julien's original proposed (informational) update.
Up until now, I haven't included the text for the IKE
socket handling question as part of the background
discussion for the new issue, but I can always go back
and add it later if need be.

Regards,
Charlie P.

Arnaud Ebalard wrote:
> Hi Julien and sorry for the latency,
>
> Julien Laganier <[email-masked]> writes:
>
>   
>>>> RFC5014 allows a sending process to express to the IP stack its
>>>> preference for a CoA to be selected as source address in outbound
>>>> packets, and then allows the process to verify that the selected
>>>> source address is indeed a CoA:
>>>>
>>>> ... snip ...
>>>>         
>>> I think you miss the point. 
>>>       
>> I guess I do...
>>     
>
> With 5014, you can manage to get a socket that will use a CoA as source
> address (with the ability to verify it is indeed a CoA). For common
> applications, I imagine that this is just fine because they simply
> do not care about the address itself but simply want to use a CoA and
> delegate the address decision to the system.
>
> For the interaction between MIPv6 and IPsec/IKE, a more direct path is
> needed (IMHO, other developers that have spent time on the code should
> comment) at various moments where the MIPv6 process must influence the
> IPsec stack and the IKE daemon in a very specific way: 
>
> - Bootstrapping (handling of transport mode SA by IKE)
> - Update of in-kernel SP/SA on movement
> - Update of IKE-daemon mirrored SP/SA on movement
> - Update of IKE_SA endpoints on movements
> - ...
>
> I think that in the specific case of bootstrapping, it would be possible
> to specifically mark the SP (or SA information to be negotiated, even if
> it would introduce a daemon/system specific issue in some way) for the
> IKE daemon to use a CoA. From your previous code samples, I think that
> the IKE daemon will manage to get a socket using a CoA as source,
> retrieve this CoA and consider it the expected source address to use for
> the negotiation of the IKE_SA (the socket is directly usable but the @
> is certainly needed for internal tasks). After scratching my head, I
> think what you propose could take off, but probably won't fly well or at
> all. An IKE daemon differs from a common app regarding handling of
> adresses: it has to be very careful and handle things at a somewhat
> lower level than a common app.
>
> I also have some questions (don't hesitate to reply with pointers if it
> is documented) associated with your expected use of 5014 for MIPv6
> bootstrapping by IKE: what happens when there are multiple addresses on
> the system (for instance a native, an ULA and a 6to4 address). What is
> their status? all CoA? The MIPv6 process will choose one specific
> address for the binding with its HoA (source of the BU when it leaves
> the MN) based on specific internal policies. What gives the insurance
> that this address will be the one that the IKE daemon will use if it
> implements 5014 for bootstrapping?
>
> To continue on that path, do you see a simple way for the IKE daemon to
> update its IKE_SA endpoints on movement with a new CoA (item 4 in my
> previous list)? How will it be warned to do the change? What are the
> expected actions to be taken? 
>
> Because a decision has already been taken on the interest of some work
> on such a mechanism by the WG, I should probably keep the following
> additional question for me: what about items 2 and 3?
>
> In the end, it is obvious that a MIPv6 process needs to interact with
> IPsec/IKE. I'd like to be proven false by some implementations (MIPv6,
> IKE, IPsec stack) that could use what is currently on the table
> (normalized documents, i.e. RFC) to provide something that works.
>
> Cheers,
>
> a+
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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: Tue, 08 Jul 2008 22:00:25 +0200

Hi,

> and add it later if need be.

Sorry for replying to your other email, that one would probably have
been more appropriate.

Thanks for your work,

Cheers,

a+

---

From: "Hui Deng" <[email-masked]>
Date: Wed, 9 Jul 2008 09:35:25 +0800

Hello, all

I agree that socket handling by IKE versus availability of the CoA
from MIPv6 is out of scope for RFC3775bis.

We'd better start a new seperated work item asap.

Thanks.

-Hui

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 09 Jul 2008 09:02:58 +0200

Hi,

> from MIPv6 is out of scope for RFC3775bis.

me too.

> We'd better start a new seperated work item asap.

I'll start a thread on that point next week if you are ok.

This will incude gathering some feedback from people that implemented
IKE+MIPv6.

IMHO, the discussion belongs (should start) on both IPsec ML and mext
ML.

a+

---

From: "Hui Deng" <[email-masked]>
Date: Wed, 9 Jul 2008 16:16:28 +0800

Hi,

I am fine with it,

http://tools.ietf.org/id/draft-qi-mip6-ikev2-interfacing-01.txt
http://tools.ietf.org/id/draft-sugimoto-mip6-pfkey-migrate-04.txt

I guess that most of the authors here go to both IPsec and
MIP6 ML as well.

Thanks

-Hui