Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-11.txt

From: Padmakumar AV <[email-masked]>
Date: Wed, 1 Jul 2009 16:24:49 +0530

Hi Vijay,

I have a doubt regarding the usage of redirect during INIT exchange.

An attacker in between spoke and hub spoofs the init exchange to anycast
address and then redirects it to another FAKE-HUB1 by specifying unicast
address of the FAKE-HUB1. FAKE-HUB1 subsequently redirects it to FAKE-HUB2
and FAKE-HUB2 to FAKE-HUB3 and go on...

Is that possible.

Thanks

Padmakumar

On Tue, Jun 16, 2009 at 11:45 PM, <[email-masked]> wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IP Security Maintenance and Extensions
> Working Group of the IETF.
>
>
>        Title           : Redirect Mechanism for IKEv2
>        Author(s)       : V. Devarapalli, K. Weniger
>        Filename        : draft-ietf-ipsecme-ikev2-redirect-11.txt
>        Pages           : 16
>        Date            : 2009-06-16
>
> IKEv2 is a protocol for setting up VPN tunnels from a remote location
> to a gateway so that the VPN client can access services in the
> network behind the gateway.  Currently there is no standard mechanism
> specified that allows an overloaded VPN gateway or a VPN gateway that
> is being shut down for maintenance to redirect the VPN client to
> attach to another gateway.  This document proposes a redirect
> mechanism for IKEv2.  The proposed mechanism can also be used in
> Mobile IPv6 to enable the home agent to redirect the mobile node to
> another home agent.
>
> A URL for this Internet-Draft is:
>
> http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-redirect-11.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>

---

From: Raj Singh <[email-masked]>
Date: Wed, 1 Jul 2009 18:58:07 +0530

Hi Padam,

It possible and avoidable by configuring a policy on client for MAX no. of
REDIRECTs.
Draft has a mention of this scenario in Section 10.

With Regards,
Raj

---

From: Padmakumar AV <[email-masked]>
Date: Thu, 2 Jul 2009 08:28:25 +0530

Hi Raj,
The case I mentioned is with usage of redirect during init exchange destined
to anycast. The router that tries to resolve the anycast address has no clue
about this as it is syntactically same as that of unicast. But an attacker
who has access to the link, precisely where anycast resolution happens can
always set override bit in the NA and win the resolution. He may not be
capable to drop the packet as mentioned in Section 10 but will be able to
redirect it either to a victim or another node or do continuous redirects. I
don't understand how the spokes resolve this problem by having a policy at
the spoke side to restrict the maximum number of redirects as its final plan
is to connect to a hub.

Thanks
Padmakumar

On Wed, Jul 1, 2009 at 6:58 PM, Raj Singh <[email-masked]> wrote:

> On Wed, Jul 1, 2009 at 4:24 PM, Padmakumar AV <[email-masked]>wrote:
>
>> Hi Vijay,
>>

---

From: Raj Singh <[email-masked]>
Date: Thu, 2 Jul 2009 08:39:00 +0530

Hi Padma,

By having a policy for MAX no of re-direct means when spoke reaches max no
of re-directs it will come to know that either it is under attack or there
is some misconfiguration. Then spoke can choose to stop trying connection
with anycast address and fall back to some other VPN gateway for connection.

Thanks,
Raj

On Thu, Jul 2, 2009 at 8:28 AM, Padmakumar AV <[email-masked]> wrote:

> Hi Raj,
> The case I mentioned is with usage of redirect during init exchange
> destined to anycast. The router that tries to resolve the anycast address
> has no clue about this as it is syntactically same as that of unicast. But
> an attacker who has access to the link, precisely where anycast resolution
> happens can always set override bit in the NA and win the resolution. He may
> not be capable to drop the packet as mentioned in Section 10 but will be
> able to redirect it either to a victim or another node or do continuous
> redirects. I don't understand how the spokes resolve this problem by having
> a policy at the spoke side to restrict the maximum number of redirects as
> its final plan is to connect to a hub.
>
> Thanks
> Padmakumar
>
>

---

From: Padmakumar AV <[email-masked]>
Date: Thu, 2 Jul 2009 09:16:53 +0530

Hi Raj,
That is exactly what I am saying. Two things:

1. permitting redirects during Init exchange (you have no choice when the
destination is anycast)
2. usage of anycast

These two are not serving any special purpose here instead it creates more
problem.

Thanks
Padmakumar

On Thu, Jul 2, 2009 at 8:39 AM, Raj Singh <[email-masked]> wrote:

> On Thu, Jul 2, 2009 at 8:28 AM, Padmakumar AV <[email-masked]>wrote:
>
>> Hi Raj,
>>> It possible and avoidable by configuring a policy on client for MAX no.
>>> of REDIRECTs.