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.
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".
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". 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".
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.
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
