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

From: Julien Laganier <[email-masked]>
Date: Thu, 5 Jun 2008 09:18:04 +0200

Folks,

I'd like to propose an additional change to RFC3775. The change is 
minor, and informative only:

Reason for change: RFC3775 mentions two times the possibility to use the 
care-of address as a source address in outgoing packets. In the first 
occurence, RFC3775 says that APIs to control this use are out-of-scope, 
but since an API that allows an application to require the care-of 
address to be used in outgoing packets has been specified since then in 
RFC5014, RFC3775bis could mention RFC5014 as an example of such an API. 
In the second occurence, RFC3775 says that a multicast application 
could use the care-of address as a source address in outgoing packets 
if it know the care-of address, but since RFC5014 allows to use the 
care-of address as a source address without requiring the application 
to knows the address itself that should be corrected in RFC3775bis. See 
below the two slights modifications, plus the additional informative 
reference.

Please let me know what you think.

Thanks,

--julien

-------------------------------------------------------------------------

OLD:

   o  The mobile node MAY choose to directly use one of its care-of
      addresses as the source of the packet, not requiring the use of a
      Home Address option in the packet.  This is particularly useful
      for short-term communication that may easily be retried if it
      fails.  Using the mobile node's care-of address as the source for
      such queries will generally have a lower overhead than using the
      mobile node's home address, since no extra options need be used in
      either the query or its reply.  Such packets can be routed
      normally, directly between their source and destination without
      relying on Mobile IPv6.  If application running on the mobile node
      has no particular knowledge that the communication being sent fits
      within this general type of communication, however, the mobile
      node should not use its care-of address as the source of the
      packet in this way.

      The choice of the most efficient communications method is
      application specific, and outside the scope of this specification.
      The APIs necessary for controlling the choice are also out of
      scope.

NEW:

   o  The mobile node MAY choose to directly use one of its care-of
      addresses as the source of the packet, not requiring the use of a
      Home Address option in the packet.  This is particularly useful
      for short-term communication that may easily be retried if it
      fails.  Using the mobile node's care-of address as the source for
      such queries will generally have a lower overhead than using the
      mobile node's home address, since no extra options need be used in
      either the query or its reply.  Such packets can be routed
      normally, directly between their source and destination without
      relying on Mobile IPv6.  If application running on the mobile node
      has no particular knowledge that the communication being sent fits
      within this general type of communication, however, the mobile
      node should not use its care-of address as the source of the
      packet in this way.

      The choice of the most efficient communications method is
      application specific, and outside the scope of this specification.
      The APIs necessary for controlling the choice are also out of
|     scope. One example of such an API is described in the IPv6 Socket 
|     API for Source Address Selection specification [RFC5014].

--------------------------------------------------------------------------

OLD:

   A mobile node that wishes to send packets to a multicast group also
   has two options:

   1.  Send directly on the foreign link being visited.

       The application is aware of the care-of address and uses it as a
       source address for multicast traffic, just like it would use a
       stationary address.  The mobile node MUST NOT use Home Address
       destination option in such traffic.

NEW:

   A mobile node that wishes to send packets to a multicast group also
   has two options:

   1.  Send directly on the foreign link being visited.

|      The application uses the care-of address as a source address for
|      multicast traffic, just like it would use a stationary address. 
|      This requires that the application either knows the care-of 
|      address, or uses an API such as the IPv6 Socket API for Source
|      Address Selection specification [RFC5014] to request the stack to
|     use the care-of address as a source address in sent packets. The
       mobile node MUST NOT use Home Address destination option in such
       traffic.

--------------------------------------------------------------------------

NEW:

18.2.  Informative References

|  [RFC5014] Nordmark, E., Chakrabarti, S., and Laganier, J., "IPv6
|            Socket API for Source Address Selection", RFC 5014, 
|            September 2007.
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 05 Jun 2008 10:22:52 +0200

Hi,

> RFC5014, RFC3775bis could mention RFC5014 as an example of such an

As a side note (I do not think this fits in the scope of RFC3775bis),
there is also a need to control the use of the CoA by the IKE daemon
during the negotiation of SA protecting BU/BA because the HoA is not yet
available (so not usable). AFAIK, This is not *explicitly* covered by
RFC 3775 and RFC 3776 and this specific case cannot be handled using the
documents you point.  

For more details on that, see draft-sugimoto-mip-pfkey-migrate-04.

Cheers,

a+

---

From: Julien Laganier <[email-masked]>
Date: Thu, 5 Jun 2008 11:27:38 +0200

Hello Arnaud,

On Thursday 05 June 2008, Arnaud Ebalard wrote:
> > Reason for change: RFC3775 mentions two times the possibility to
> > use the care-of address as a source address in outgoing packets. In
> > the first occurence, RFC3775 says that APIs to control this use are
> > out-of-scope, but since an API that allows an application to
> > require the care-of address to be used in outgoing packets has been
> > specified since then in RFC5014, RFC3775bis could mention RFC5014
> > as an example of such an API.
>
> during the negotiation of SA protecting BU/BA because the HoA is not
> yet available (so not usable). AFAIK, This is not *explicitly*
> covered by RFC 3775 and RFC 3776 and this specific case cannot be
> handled using the documents you point.

Why couldn't the IKE process use RFC5014 to ask the IP stack to put the 
CoA in packets it sends?

--julien

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 05 Jun 2008 12:18:16 +0200

Hello,

> Why couldn't the IKE process use RFC5014 to ask the IP stack to put the 

This is not the issue; Here is how things happen: the BU created by the
MIPv6 process, uses the CoA as source address in the end (when leaving
the MN) but the packet matches the SP protecting the signaling
traffic. This SP uses the HoA and not the CoA. If no SA is available, a
key manager will handle the negotiation of the SA. The SA being
negotiated also use the HoA. The point is that the key manager usually
selects the source address of the SA being negotiated to perform the
negotiation: in *that* specific case, this cannot be done and the IKE
daemon needs to be told to use the CoA.

This is decribed in details in the pointer I sent in my previous post.

Cheers,

a+

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

---

From: "Hui Deng" <[email-masked]>
Date: Thu, 5 Jun 2008 23:03:47 +0800

absolutely correct,
Hope more working group people will be awared of this,

thanks for the explanation

-Hui

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 5 Jun 2008 13:38:26 -0400

> RFC 3775 and RFC 3776 and this specific case cannot be 

Its not clear what is "not explicitly" covered in 3775 and 3776. RFC
3776 says

   o  In addition to the rules above, if dynamic keying is used, the key
      management protocol MUST use the care-of address as the source
      address in the protocol exchanges with the mobile node's home
      agent.

Vijay

---

From: Arnaud Ebalard <[email-masked]>
Date: Fri, 6 Jun 2008 10:22:49 +0200

Hi

>       address in the protocol exchanges with the mobile node's home

Yes, 3776 requires (MUST) the key manager to use the CoA but provides
no clue on how to do that (i.e. find out which address on the system
is the CoA). One could say this is an implementation issue but this is
a bit simplistic (IMHO) to drop the issue.

Cheers,

a+

---

From: Julien Laganier <[email-masked]>
Date: Fri, 6 Jun 2008 11:44:21 +0200

On Friday 06 June 2008, Arnaud Ebalard wrote:
> > > As a side note (I do not think this fits in the scope of
> > > RFC3775bis), there is also a need to control the use of the CoA
> > > by the IKE daemon during the negotiation of SA protecting BU/BA
> > > because the HoA is not yet
> > > available (so not usable). AFAIK, This is not *explicitly*
> > Its not clear what is "not explicitly" covered in 3775 and 3776.
> > RFC 3776 says
> >
> >    o  In addition to the rules above, if dynamic keying is used,
> > the key management protocol MUST use the care-of address as the
> > source address in the protocol exchanges with the mobile node's
> > home agent.
>
> is the CoA). One could say this is an implementation issue but this
> is a bit simplistic (IMHO) to drop the issue.

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:

uint32_t preferences = IPV6_PREFER_SRC_COA;

s = socket(AF_INET6,...);

setsockopt(s, IPV6_ADDR_PREFERENCES, (void *) &preferences,
                   sizeof (preferences));

connect(s, dst_addr, sizeof(dst_addr));

getsockname(s, src_addr, sizeof(src_addr));

if (inet6_is_srcaddr(src_addr, IPV6_PREFER_SRC_COA) != 1)
	return -1;

--julien

---

From: Arnaud Ebalard <[email-masked]>
Date: Fri, 6 Jun 2008 12:07:43 +0200

Hi,

On Fri, Jun 06, 2008 at 11:44:21AM +0200, Julien Laganier wrote:
> ... snip ...

I think you miss the point. Please, Julien, consider the following
question and try to explain how things should happen (sequence of
events) with what is on the table at the moment (3775, 3776, 5014,
...): 

How (from who, using which interface, ...) does the IKE daemon *gets*
the address?

The code you provide below might have an interest for the source
(MIPv6 process), but the IKE daemon is more an indirect helper that
gets triggered by the IPsec stack. 

Cheers,

a+

---

From: Julien Laganier <[email-masked]>
Date: Fri, 6 Jun 2008 13:49:30 +0200

Hello Arnaud,

On Friday 06 June 2008, Arnaud Ebalard wrote:
> > > > > RFC3775bis), there is also a need to control the use of the
> > > > > CoA by the IKE daemon during the negotiation of SA protecting
> > > > > BU/BA because the HoA is not yet
> > > > > covered by RFC 3775 and RFC 3776 and this specific case
> > > > > cannot be handled using the
> > > > > documents you point.
> > > >
> > > > Its not clear what is "not explicitly" covered in 3775 and
> > > > 3776. RFC 3776 says
> > > >
> > > >    o  In addition to the rules above, if dynamic keying is
> > > > used, the key management protocol MUST use the care-of address
> > > > as the source address in the protocol exchanges with the mobile
> > > > node's home agent.
> > >
> > > Yes, 3776 requires (MUST) the key manager to use the CoA but
> > > provides no clue on how to do that (i.e. find out which address
> > > on the system is the CoA). One could say this is an
> > > implementation issue but this is a bit simplistic (IMHO) to drop
> > > the issue.
> >
> > 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...

> Please, Julien, consider the following question and try to explain how
> things should happen (sequence of events) with what is on the table at
> the moment (3775, 3776, 5014, ...):
>

Ok, I really tried, and I'm sorry but the only answer I find is that the 
IKE daemon just uses the sample code below.

I must really be missing something here...

It would really help if you could point out why an IKE daemon using the 
sample code below would not get the CoA in dst_addr and in packets it 
sent. 

Cheers,

--julien

---

From: [email-masked] (Arnaud Ebalard)
Date: Sun, 08 Jun 2008 14:21:18 +0200

Hi Julien and sorry for the latency,

>> I think you miss the point. 

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+