Re: [Softwires] [BEHAVE] Some Thought about the AutomaticTunnelAddress

["Templin, Fred L" <Fred.L.Templin at boeing.com>]

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
fred.l.templin at boeing.com

> -----Original Message-----
> From: eric.burgey at orange-ftgroup.com [mailto:eric.burgey at orange-ftgroup.com]
> Sent: Thursday, September 17, 2009 7:45 AM
> To: remi.despres at free.fr; xuxh at huawei.com
> Cc: softwires at ietf.org; Templin, Fred L; behave at ietf.org
> 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 : behave-bounces at ietf.org [mailto:behave-bounces at ietf.org] De la part de Rémi Després
> Envoyé : jeudi 17 septembre 2009 10:40
> À : Xu Xiaohu
> Cc : softwires at ietf.org; '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
> Behave at ietf.org
> https://www.ietf.org/mailman/listinfo/behave