Hi Eric, > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Friday, September 18, 2009 7:34 AM > To: Templin, Fred L > Cc: [email protected]; [email protected]; [email protected]; [email protected] > Subject: RE: [BEHAVE] [Softwires] Some Thought about the > AutomaticTunnelAddress > > Thanks Fred, > > Thanks Fred, > You are right it is difficult to protect tunnelling mechanism against > spoofing attacks without ip- > proto-41 and ingress filtering in site border router. > A major enterprise or an ISP may use more than one single ISATAP link.
OK. > But the point is, as you have written in chapter 4 of RFC 5214 , > >"The domain of applicability for this technical specification is automatic > >>tunneling of IPv6 > packets in IPv4 for ISATAP nodes within sites that >observe the security > considerations found in this > document, including host->to-router, router-to-host, and host-to-host > automatic tunneling in certain > >enterprise networks and 3GPP/3GPP2 wireless operator networks. (Other > >>scenarios with a sufficient > trust basis ensured by the mechanisms specified >in this document also fall > within this domain of > applicability.)", > Automatic tunnelling must be limited to a "Site". The statement beginning: "Other scenarios with a sufficient trust basis..." is the one to consider when the "site" we are considering is the public Internet itself. The check for '*::0200:5EFE:V4ADDR' updates this statement. > Even if I have not found a precise definition of a "Site" IMHO it means that > there is an organisation > able to create the trust inside the "Site". The "organization" in this case is the IANA that delegated the public IPv4 addresses, along with the collective administrative authorities of all BGP routers in the DFZ. > Such organisation is able to know all IPv4 addresses > allocated to ISATAP router or all 6 to 4 router used to interconnect this > site with internet and to > prohibit automatic tunnelling between 2 ISATAP routers inside the "Site" or > between an ISATAP router > and 6 to 4 router inside the "Site". In some sites, configuring ISATAP/6to4 routers with a list of all other ISATAP/6to4 routers - and then using that list for filtering purposes - might not scale well. This is definitely true for the case of the public Internet as a "site", and probably also true for many large enterprises. > So if these ISATAP-ISATAP or ISATAP-6_to_4 tunnels are prohibited inside the > "Site", and if the > automatic tunnelling process is limited to intra-site tunnels, I don't see > how the loop described in > REMI DESPRES mail can be closed in the IPv4 domain. As above, populating a list of all IPv4 addresses of ISATAP/6to4 routers on each router might not scale well in many environments. So, a simple solution is to use the ISATAP router neighbor cache to avoid looping. In particular, an ISATAP router *with a coherent neighbor cache* should only accept/send a tunneled packet with dst/src address other than FE80::* IFF the tunnel far end is a known neighbor. Within enterprise networks protected by site border routers there are two ways to ensure a coherent neighbor cache: 1) administrative assurance that no IPv4 spoofing is possible within the enterprise, or 2) secure neighbor discovery. Within the global Internet as a site, we can rely on neither of these and have only the '*::0200:5EFE:V4ADDR' check as protection. You should probably also have a look at the thread titled: "routing loop attacks using IPv6 tunnels" in the v6ops and 6man lists. Fred [email protected] > Eric BURGEY > > -----Message d'origine----- > De : Templin, Fred L [mailto:[email protected]] > Envoyé : jeudi 17 septembre 2009 19:26 > À : BURGEY Eric RD-CORE-ISS; [email protected]; [email protected] > Cc : [email protected]; [email protected] > Objet : RE: [BEHAVE] [Softwires] Some Thought about the AutomaticTunnelAddress > > Eric, > > The point is that ISATAP can be used with public IPv4 > addresses (in which case the IPv6 address is constructed > as: "FOO::0200:5EFE:V4ADDR") and there is no guarantee > in that case that the ISATAP router is located behind an > ip-proto-41 nor ingress-filtering site border router. Plus, > I know of at least one major enterprise network that uses > public IPv4 addresses internally, and the network is much > too large to be covered by a single ISATAP link. > > This discussion should probably by synchronized with the > one taking place on the v6ops, 6man and secdir lists. > > Fred > [email protected] > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > > Sent: Thursday, September 17, 2009 7:45 AM > > To: [email protected]; [email protected] > > Cc: [email protected]; Templin, Fred L; [email protected] > > Subject: RE: [BEHAVE] [Softwires] Some Thought about the > > AutomaticTunnelAddress > > > > Hello, > > Xu Xiaohu comment is right but probably be too much restrictive. > > Excluding all public IPv4 addresses is too strict and not enough because it > > does not excludes 6 to > 4 > > gateways between the local private network and the IPv6 network with a > > private IPv4 address. > > > > ISATAP use an IPv6 operator prefix instead of a well known prefix, so it > > means that ISATAP is built > > to ensure IPv6 connectivity of IPv4 Islands inside an IPv6 network managed > > by a specific operator. > > So the encapsulation of IPv6 packet into IPv4 done by the gateway must be > > restricted to IPv4 > > destination addresses managed by this operator (the ISATAP equipment > > operator) excluding all IPv4 > > addresses managed by this operator and allocated to ISATAP, 6 to 4 gateway > > or any other gateway > > between the IPv4 network and the IPv6 network like for example IVI-T > > gateways. > > > > > > This limitation can be implemented through an access list in the ISATAP > > gateway, in IVI-T gateways > or > > in any other gateway between the IPv4 network and the IPv6 network doing > > encapsulation of IPv6 > > packet, with a prefix allocated to an operator, in IPv4 packet. > > > > > > Eric BURGEY > > > > -----Message d'origine----- > > De : [email protected] [mailto:[email protected]] De la part de > > Rémi Després > > Envoyé : jeudi 17 septembre 2009 10:40 > > À : Xu Xiaohu > > Cc : [email protected]; 'Templin, Fred L'; 'Behave WG' > > Objet : Re: [BEHAVE] [Softwires] Some Thought about the > > AutomaticTunnelAddress > > > > > > Xu, > > > > Thanks for you answer. > > Further comment below. > > > > > > Le 17 sept. 09 à 05:17, Xu Xiaohu a écrit : > > > > > In your msg > > > (http://www.ietf.org/mail-archive/web/behave/current/ > > > msg06816.html), you > > > said "... Suffice it to say that a 6to4 relay router may need, to > > > be safe, > > > to look at IPv4 addresses that are embedded in ISATAP IPv6 > > > addresses. In the > > > above example, if the 6to4 relay router sees that the IPv4 embedded > > > address > > > in the IPv6 destination is its own IPv4 address 192.88.99.1, it can > > > discard > > > the packet and thus prevent the loop". However, I feel this is not > > > a good > > > idea for a 6to4 router to check the ISATAP address. In fact, the > > > routing-loop attack can be easily avoided by using a private IPv4 > > > address, > > > rather that a public IPv4 address as the ISATAP tunnel endpoint > > > address on > > > the ISATAP router. > > > > If the IPv4 address of an ISATAP router is private, the attack > > scenario below doesn't exists, YES. > > > > But 5214 says in its introduction that "ISATAP enables automatic > > tunneling whether global or private IPv4 addresses are used". > > To prevent all routing-loop attacks, 6to4 relay routers should > > therefore also deal with ISATAP routers that have global IPv4 addresses. > > > > As a matter of facts, ISATAP can be useful with a global IPv4 address > > in a large private network that has enough global IPv4 addresses to > > use them internally: this provides IPv6 connectivity to dual-stack > > hosts that support ISATAP (e.g. with Windows or Linux AKAIK). > > > > > > > Hence, I don't think the routing-loop attack prevention is a > > > justification > > > for the "IID-format constraint". > > > > I also wish it would not have been a justification, but for the > > reason above I believe it is one we have to live with :-(. > > > > Did I miss anything? > > > > Regards, > > RD > > > > > > > > > For a brief illustration of one instance of the the attack, here is an > > > example: > > > > > > +-------------------------------------------------------+ > > > | IPv6 IPv6 packet | > > > |Internet dst6: 2002:198.16.9.9::1 | > > > | src6: 2001:db8:1::200:5efe:192.88.99.1| > > > | | | > > > | V | > > > | .--------------->--------------. | | > > > | / \| | > > > +--------+----------------------------------+-----------+ > > > | | > > > 2001:db8:1::/48 2002::/16 > > > +---------+ +---------+ > > > | ISATAP | | 6to4 | > > > +---------+ +---------+ > > > 198.16.9.9 192.88.99.1 > > > | | > > > +--------+---------+ | > > > | IPv4 ^ | | > > > | site ^ | | > > > | ^ | V > > > | ^ | | > > > +--------+---------+ | > > > 198.16.9.0/24 | > > > | | > > > | | > > > +--------+----------------------------------+-----------+ > > > | IPv4 \ / | > > > |internet '----------------<-------------' | > > > | IPv6 in IPv4 packet | > > > | dst4: 198.16.9.9 | > > > | src4: 192.88.99.1 | > > > | | > > > +--------+----------------------------------+-----------+ > > > > > _______________________________________________ > > Behave mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
