Subject: AW: [Ipsec] MIPv6 bootstrapping and IKEv2

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 26 Oct 2005 01:17:48 +0200

hi francis, 

this idea sounds similar to ted:

Fluhrer, S., "Tunnel Endpoint Discovery", draft-fluhrer-ted-00 (expired), November 2001. 

it is true that the bootstrapping solution for the split scenario does not address the problem of finding the home agent. but, why is this even necessary given the number of options you typically have? here is a short list from a old version of the <draft-tschofenig-v6ops-secure-tunnels-0x>: 

9.  Tunnel Endpoint Discovery

   The IKEv2 initiator needs to know the address of the IKEv2 responder
   for IKEv2 signaling.  A number of ways can be used to provide the
   initiator with this information, for example:

   o  Using off-band mechanisms, e.g., from the ISP's web page.

   o  Using DNS to look up a service name by appending it to the DNS
      search path provided by DHCPv4 (e.g.
      "tunnel-service.example.com").

   o  Using a DHCP option.

   o  Using a pre-configured or pre-determined IPv4 anycast address.

   o  Using other, unspecified or proprietary methods such as TED (see
      [I-D.fluhrer-ted]).

   For the purpose of this document it is assumed that this address can
   be obtained somehow.  Once the address has been learned, it is
   configured as the tunnel end-point for the configured IPv6-over-IPv4
   tunnel.

... and i should add the recent proposal for the integrated scenario using dhcp. 
<draft-ietf-mip6-bootstrapping-integrated-DHC-00.txt> 

ciao
hannes

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Francis Dupont
> Gesendet: Mittwoch, 26. Oktober 2005 00:20
> An: [email-masked]
> Betreff: [Ipsec] MIPv6 bootstrapping and IKEv2
> 
> 
> IKEv2 is assumed to become the default mechanism in MIPv6 
> bootstrapping,
> both because the MIPv6 security between a mobile node and its 
> home agent
> (HA) is based on IPsec and because IKEv2 is efficient, provides
> configuration, support legacy authentication, etc.
> Look at draft-ietf-mip6-ikev2-ipsec-04.txt ...
> 
> But something IKEv2 doesn't (yet!) know to do is the assignment of
> the HA address, mainly because when you are talking with the HA
> you already have its address... MIPv6 has some HA address discovery
> mechanisms (a problem very similar to the SG discovery) and is looking
> for HA (address) assignment mechanisms.
> 
> HAs on the same link share an IPv6 anycast address (a group address
> like multicast but messages are delivered to one member of the group
> and the format is the same than for unicast. IPv6 anycasts share some
> properties with multicasts: they must not use as source addresses and
> a stream of messages is not required to be delivered to the 
> same node).
> 
> A proposal is the initiator (aka mobile node aka VPN client) sends
> the first message (IKE_SA_INIT) to the anycast address, the receiving
> HA forwards it to the "best" HA which answers using its own unicast
> address. The initiator keeps this address as the responder address
> for further messages.
> 
> IMHO we should enforce Cookie mechanism in this case:
>  - we always get a full IKE_SA_INIT exchange using the right addresses
>  - we can't mess NAT detection or other things relying on addresses
>  - an anycast address is a good target for attacks so to always
>    consider it is under attack is just pessimism
> 
> Is there a problem I couldn't see? Is it a good/bad/don't-care idea?
> (BTW it is not mine)
> 
> Regards
> 
> [email-masked]
> 
> _______________________________________________
> Ipsec mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipsec
> 

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Oct 2005 10:12:08 +0200

In your previous mail you wrote:

=> note that discovery is not assignment. MIPv6 has already two
discovery mechanisms (ICMP anycast-based, DNS SRV RR).

   ... and i should add the recent proposal for the integrated
   scenario using dhcp <draft-ietf-mip6-bootstrapping-integrated-DHC-00.txt>

=> this proposal covers only a particular case. A HA assignment for IKEv2
should cover all the cases using IKEv2.
   
Regards