On Thu, 20 Dec 2001, Brian E Carpenter wrote: > Incoming 6to4 traffic to a 6to4 site is recognized by the > fact that the destination IPv6 address is a 2002: address. > (The source may be anything if the traffic is from a relay.)
Note: for relays, this is not enough identification. And this is a problem when boxes implement e.g. both 6to4 and autotunneling. Rules would be so much simpler if one could have an easy "relay" on/off toggle. I'm not sure if anyone has implemented 6to4 this way? I've seen two and both seem to apply the principle of "least security" that is, open to all because relays require it. Also note that decapsulation rules in RFC3056 5.3 do not require that the destination address is 2002. (Of course, the packet must be sent "manually" if it isn't, but encapsulation is not the point). So, it would be "legal" to send a packet like: src=1.1.1.1 dst=2.2.2.2 src6=2002:0101:0101:: dst6=<whatever> > As we've always said, 6to4 relays need to know who their > cients are. This is the RFC 3056 model. > > I suspect that in the end, we will build lists of "trusted" > 6to4 relays. It might be like my personal firewall, which > asks me whether to admit packets when it first sees a new > port being probed: > > Incoming IPv6 traffic from router.hacker.net; OK? That is an improvement, but it has to contain *all* relays in the world. I don't think that kind of solution is ever going to scale. Alternatively, if we could advertise more specifics than 2002::/16 we could control which relay is to be trusted and used. But this has its own problems.. Alternatively, we could trust the anycast address 192.88.99.1. Whoever can spoof that, could do anything. Currently, our relay is using only the anycast address, but not for security reasons. > Pekka Savola wrote: > > > > First, let me point out a property of overloading protocol 41, from my > > draft: > > > > --8<-- > > There is a problem with multiple transition mechanisms if security is > > implemented. This may vary a bit from implementation to > > implementation. > > > > Consider three mechanisms using automatic tunneling: 6to4, ISATAP > > [ISATAP] and Automatic Tunneling using Compatible Addresses [MECH]. > > > > All of these use IP-IP (protocol 41) [IPIP] IPv4 encapsulation with, > > more or less, a pseudo-interface. > > > > When a router, which has any two of these enabled, receives an IPv4 > > encapsulated IPv6 packet: > > > > src_v4 = 10.0.0.1 > > dst_v4 = 20.20.20.20 > > src = 3ffe:ffff::1 > > dst = 2002:1010:1010::2 > > > > what can it do? How should it decide which transitionary mechanism > > this belongs to; there is no "transitionary mechanism number" in IPv6 > > or IPv4 header to signify this. > > > > Without any kind of security checks (in any of implemented methods) > > these often just "work" as the mechanisms aren't differentiated but > > handled in "one big lump". > > > > Configured tunneling [MECH] does not suffer from this as it is point- > > to-point, and based on src/dst pairs of both IPv4 and IPv6 addresses > > it can be deduced which logical tunnel interface is in the question. > > > > Solutions for this include not using more than one automatic > > tunneling mechanisms in the same system or binding different > > mechanisms to different IPv4 addresses. > > --8<-- > > > > In this case, consider a node which has configured tunnels, autotunnel and > > 6to4. > > > > If it receives a packet with: > > > > src=1.1.1.1 > > dst=2.2.2.2 > > src6=fe80::1 > > dst6=fe80::2 > > > > it cannot know which mechanism this was intended for. > > > > If configured tunnel was between 1.1.1.1 and 2.2.2.2, it could try to > > guess this must be meant for the configured tunnel. (I haven't looked into > > 6to4 multicast yet, but this kind of link-local assumption might not > > hold). > > > > however, if the packet is e.g.: > > > > src6=::1.1.1.1 > > dst6=fe80::2 > > > > is it for configured, autotunnel 6to4 (if the box is a 6to4 relay) or > > what? > > > > There are more unclear scenarios like this. > > > > This makes security checks rather difficult to implement. > > > > On Wed, 19 Dec 2001, Tony Hain wrote: > > > Pekka Savola wrote: > > > > Undeniably, you can input packets with: > > > > > > > > - link-local source (here: ff80::1) > > > > - link-local destination (here: ff80::2) > > > > - hop limit 255 > > > > > > > > in the tunnel interface. > > > > > > Not if the tunnel interface consistency check is applied to prevent it. > > > If you don't want to accpet link-local packets over the tunnel you are > > > not required to. Accepting packets through a filter needs to be done for > > > each of the interfaces. If you are willing to accept packets from any > > > IPv4 source, but not any IPv6 source, then you have to recheck the > > > packet once it is decapsulated. > > > > Autotunneling has no such checks, and 6to4 just mentions this (in the > > context of source addresses). Destination address? By RFC3056, relays > > cannot have either or these checks. > > > > Also see above. > > > > > > Now, if the router has 'ff80::2' configured as one of it's > > > > pseudo-interface addresses, that address can be reached via tunneling > > > with > > > > hop limit 255 from anywhere. > > > > > > > > See the potential problem here? > > > > > > Yes, the node is reachable using IPv4 from anywhere, and you are trying > > > to make believe that adding IPv6 is somehow a bigger problem. What is > > > the point? > > > > IPv6 has local-scoped addresses that have a special significance. > > > > Via mechanisms like 6to4 (depending on whether optional security > > precautions are taken) one can inject IPv4 packets in the internal network > > that would not have passed the IPv4 checks. > > > > > If packets can get there via IPv4, the fact that some of them > > > may be encapsulated IPv6 makes no difference. If a node has a policy > > > that packets over the global IPv4 interface go through some firewall > > > process, then the same policy MUST apply to the tunnel interface. If it > > > doesn't the site administrator is brain-dead and deserves what he gets. > > > > The site administrator is braindead because he allows people to use any > > (it's all or nothing) IPv6 tunneling mechanism? Note that IPv4 site > > administrator cannot know whether it's being used for configured, > > automatic or whatever tunnels. Do we want to make these braindead site > > operators block protocol 41? > > > > The point is, the checking is de-centralized from IPv4 firewalls to tunnel > > endpoints. If every host used 6to4 (the 6to4 host+router scenario), every > > 6to4 host would have to implement these checks, firewall policies etc. > > This is when site operators say: "no thanks! No ipv6 here please!". Is > > that what we want? > > > > > If your complaint is that a site administrator can't apply grainular > > > policy to a link-local address over a tunnel, you are right and they > > > simply need to block all FE80 addresses on that interface. > > > > Insecure by default? Hopefully not for the joe-random-user -orieted > > methods like 6to4 or shipworm at least. > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
