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

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 <paav.cisco@gmail.com> 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
>
>
> On Wed, Jul 1, 2009 at 6:58 PM, Raj Singh <rsjenwar@gmail.com> wrote:
>
>> 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
>>
>>
>> On Wed, Jul 1, 2009 at 4:24 PM, Padmakumar AV <paav.cisco@gmail.com>wrote:
>>
>>> 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, <Internet-Drafts@ietf.org> 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
>>>> IPsec@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>
>>>>
>>>
>>> _______________________________________________
>>> IPsec mailing list
>>> IPsec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>
>>>
>>
>