Subject: Re: [Mip6] AD review of draft-ietf-mip6-bootstrapping-split

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 01 Mar 2007 15:24:51 -0800

Kilian Weniger wrote:

>>>    If an anycast address is returned in response to DNS 
>> resolution of
>>>    an FQDN, the IKEv2 transaction between the Mobile Node and Home
>>>    Agent is slightly modified. The Mobile Node sends the IKE_SA_INIT
>>>    request to the anycast address. The node which has the anycast
>>>    address assigned to one of its network interfaces selects a Home
>>>    Agent address from the set of Home Agents managed by the 
>> node, and
>>>    forwards the IKE_SA_INIT. If the set of Home Agents is 
>> empnty, the
>>>    node simply drops the packet. The Home Agent answers 
>> using its own
>>>    address, and includes an "under attack" cookie, in 
>> accordance with
>>>    RFC 4306 [7]. The Mobile Node notes the Home Agent address and
>>>    resends the IKE_SA_INIT message to the Home Agent, along with the
>>>    cookie. 
>> There are several issues in this. First, I think I understand
>> at least one reason why the cookie exchange makes sense,
>> but is that something that has to be mandated? What if the
> 
> There were two reasons for mandating the cookie exchange:
> 1. anycast HA address is typically a single well-known and public
> address, which makes it a possible target of DoS attacks. 
> 2. less impact on IKEv2 exchange, since the complete IKEv2 exchange is
> done with unicast address.

In my mind, the second one was the main reason.

> If nobody sees a big issue with an anycasted IKE_SA_INIT followed by a
> unicast IKE_SA_INIT response without cookie, I'm fine with "SHOULD"
> instead of "MUST" for the cookie (Vijay, from your reply it seems you
> have concerns?). Using the cookie due to reason 1 can be left to
> operator's decision IMHO.

Lets get the mechanism right. I prefer not to add yet
another optional mechanism. If its not needed we should
remove it.

The way I see it the cookie is used by the responder (the
HA that sent the cookie) to tie the first IKE_SA_INIT
exchange with the second one. The cookie is also used by
the initiator (the mobile node) to figure out why its
first IKE_SA_INIT exchange did not succeed and why it
needs to do a second IKE_SA_INIT exchange.

>> home network simply figures out what HA should be used and
>> responds in the usual IKEv2 way?
> 
> yes, IMHO we can relax this and it can be left to HA
> configuration/operator's decision whether HA always includes cookie or
> not (see above). 

I would prefer one concrete way of doing it.

>> Secondly, responding with the home agent's own address
>> is in violation of a MUST in RFC 4306, Section 2.11. I talked
>> to one of the IKEv2 designers about this and his advice
>> was that the MUST may have been a mistake. Or at least it
>> should be limited to unicast addresses, and leave the behaviour
>> for anycast addresses for future documents. In any case,
>> this deviation from RFC 4306 should be highlighted and
>> justified in the document.
> 
> we could add something like "the MUST in RFC4306 refers to unicast
> only". 

How about the following text?

   Note that when the mobile node sends an IKE_SA_INIT request
   message to an anycast address, the response comes back from
   a unicast address.  RFC 4306 requires that the responder MUST
   use the destination address on the request message as the
   source address on the response message.  It is likely that
   RFC 4306 was talking about unicast addresses in that context.
   The mobile node implementation compliant to this specification
   must relax the requirement from RFC 4306 and be willing to
   process the response from an unicast address when it sends a
   request to an anycast address.

>> The third issue is the above notion of a node that owns an
>> anycast address. How does this relate to the usual arrangement
>> where the routing system handles the delivery of the anycast
>> packets to the "closest" place that advertises that address?
> 
> all HAs on home link should have same distance in hops from MN, so there
> shouldn't be any impact on the notion of delivery of anycast packets by
> the routing system. This forwarding allows the operator to control the
> assignment of a HA on the home link on a per-case basis based on
> parameters defined by operator(e.g., load).
> 
>> When you say "forwards", do you mean that the packet is
>> forwarded unmodified, or that the particular home agent's
>> address replaces the destination address? 
> 
> good question. Some options for forwarding are 
> 1. MAC address replacement, 
> 2. IP tunneling,
> 3. IP address replacement. 
> 
> The first (and maybe the second) option have the issue that the receiver
> of a unmodified packet has no way to determine whether the packet was
> already forwarded by another HA or comes from the MN. Hence, it would
> apply the same mechanism to forwarded packets as to packets received
> directly from the MN. This means that unmodified packets may be
> forwarded many times, if the considered parameters (e.g., load) have
> changed since the last forwarding or are not the same at all HAs. This
> could be prevented by modifying forwarded packets somehow, so that the
> HA is able to identify those and doesn't apply the forwarding mechanism
> to already forwarded packets. This is not needed if the third option is
> used.

We already say the following in the draft.

    Note that this procedure requires the implementation of anycast
    forwarding in such a way that the Home Agent can distinguish
    between an IKE_SA_INIT forwarded through an anycast address and
    one sent directly from the Mobile Node.

>> Four: What happens when the IKE SA dies or is
>> deleted, but a binding for the mobile node remains
>> in the selected home agent? Will the mobile node
>> re-establish the IKE SA using the anycast address,
>> or the address of the selected home agent?
> 
> Yes, some text should be added about that. The MN could first try to
> re-establish the SA with the current HA's unicast address, as Vijay
> said. But if this fails, the MN should try to find a new HA, e.g., by
> using the anycast HA assignment. 

How about the following text?

   A mobile node's security associations with its home agent may
   expire while it still has a valid binding cache entry at the
   the home agent.  In this case, the mobile node MUST NOT use an
   anycast address as the destination address in the IKE_SA_INIT
   exchange to setup new security associations.  It MUST try to
   setup security associations with its existing home agent.

Vijay

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

---

From: "Kilian Weniger" <[email-masked]>
Date: Fri, 2 Mar 2007 13:56:22 +0100

Hi Vijay,

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Freitag, 2. März 2007 00:25
> To: Kilian Weniger
> Cc: Jari Arkko; Mobile IPv6 Mailing List; James Kempf
> Subject: Re: [Mip6] AD review of draft-ietf-mip6-bootstrapping-split
> 
> Kilian Weniger wrote:
> 

Those are reasons for having a cookie when two IKE_SA_INIT exchanges are done. I assume that we only have one IKE_SA_INIT exchange if we don't use the cookie. Then the question is whether there is a problem, when an IKE_SA_INIT *anycast* request is followed by an IKE_SA_INIT unicast response *without cookie*, followed by the usual IKE_SA_AUTH exchange etc, i.e., is there a problem with the following exchanges:

        Initiator                         Responder ("best" HA) 
       -----------                        --------------------- 
    
       (IP_I:500 -> ANYCAST:500) 
       HDR(A,0), SAi1, KEi, Ni   --> 
    
                                 (IP_R:500 -> IP_I:500) 
                             <-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ] 

       (IP_I:500 -> IP_R:500) 
       HDR(A,B), SK {IDi, [CERT,] [CERTREQ,]  
       [IDr,]AUTH, SAi2, TSi, TSr} --> 
    
                                 (IP_R:500 -> IP_I:500) 
                             <-- HDR(A,B), SK {IDr, [CERT,] AUTH, 
                                                 SAr2, TSi, TSr} 
	...

>    request to an anycast address.

sounds good to me.

>     one sent directly from the Mobile Node.

Right. But the current text doesn't say how the IKE_SA_INIT can be forwarded and how the HA can distinguish between forwarded packets and packets coming from the MN. Since this is required for interoperability, don't we need to specify this?

>    setup security associations with its existing home agent.

Sounds good to me. We could additionally specify the behaviour for the case that the IKE SA dies before the lifetime expires. In this case the mobile node should try to find a new home agent IMHO:

     If the security associations with the home agent die before 
     they expire, e.g., because the mobile node detects that the 
     peer is dead or because the peer deleted the security  
     associations), the mobile node should try to bootstrap with a 
     new home agent using one of the mechanisms specified in this 
     document.

Regards,

Kilian

> Vijay

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 02 Mar 2007 14:17:08 -0800

>         Initiator                         Responder ("best" HA) 

I understood what you were saying in the earlier mail
itself. I think the cookie is necessary since it ties
the two IKE_SA_INIT exchanges together.

> Right. But the current text doesn't say how the IKE_SA_INIT can be forwarded and how the HA can distinguish between forwarded packets and packets coming from the MN. Since this is required for inte…

We currently have this out of scope. Do we have consensus
on one solution?

>      new home agent using one of the mechanisms specified in this 

I am not so sure about the second paragraph. Unless you
know why the HA deleted the security associations, it is
hard to recommend a particular behavior. What if the HA
deleted the security associations but not the binding
cache entry? :)

Vijay

---

From: "Kilian Weniger" <[email-masked]>
Date: Mon, 5 Mar 2007 17:11:19 +0100

> Sent: Freitag, 2. März 2007 23:17
> To: Kilian Weniger
> > Those are reasons for having a cookie when two IKE_SA_INIT 
> exchanges are done. I assume that we only have one 
> IKE_SA_INIT exchange if we don't use the cookie. Then the 
> question is whether there is a problem, when an IKE_SA_INIT 
> *anycast* request is followed by an IKE_SA_INIT unicast 
> response *without cookie*, followed by the usual IKE_SA_AUTH 
> exchange etc, i.e., is there a problem with the following exchanges:
> > 

I think we are talking past each other. My question was whether there would be a problem if we use a *single* IKE_SA_INIT exchange with anycasting, i.e., the initial IKE_SA_INIT request is anycasted, the subsequent IKE_SA_INIT unicast response doesn't contain a cookie, and the next exchanges are the usual IKE_AUTH, etc.

> > Right. But the current text doesn't say how the IKE_SA_INIT 
> can be forwarded and how the HA can distinguish between 
> forwarded packets and packets coming from the MN. Since this 
> is required for interoperability, don't we need to specify this?
> 

MAC destination address replacement is problematic IMHO, since the HA may not be able to distinguish between forwarded and non-forwarded IKE_SA_INIT requests. I prefer IP tunneling, this seems to be the cleaner than IP destination address replacement. The HA would be able to identify forwarded IKE_SA_INIT requests as they are received over an IP tunnel.

What do others think?

> > Sounds good to me. We could additionally specify the 
> behaviour for the case that the IKE SA dies before the 
> lifetime expires. In this case the mobile node should try to 
> find a new home agent IMHO:
> > 

I think we need to specify a behaviour, especially when there is a problem with one of the possible MN behaviors. 

> deleted the security associations but not the binding

The receiver of the anycast IKE_SA_INIT request could forward it to the HA with the MN's BCE, if there is an HA on the link with an active BCE for the MN. This of course would require that the receiver knows the BCEs of all HAs on the link.

Regards,

Kilian