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 <rsjen...@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.ci...@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-dra...@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 >> >> >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
