On Thu, 13 Dec 2001, Robert Elz wrote: > Date: Thu, 13 Dec 2001 11:23:32 +0200 (EET) > From: Pekka Savola <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > > | If Attacker A pings 2002:0102:0304::1 it works no problems. If attacker > | pings 3ffe:ffff:1::1, there is no reply as the network is not reachable to > | the Internet on purpose. > > Unless it is carefully filtered, it is reachable, just harder. Relying > on failing to advertise routes as an alternative to filtering is folly.
It is only available from local network (that is, where you can add e.g. 'route add -host 127.0.0.1 <some node>' anyway). > | Target node T decapsulated the IPv4 packet and delivers the IPv6 packet to > | 3ffe:ffff:1::1 without complaints. > > If the address is supposed to be filtered, the filters need to apply > to decapsulated packets just as much as regular ones. If you set up > (or permit) a tunnel to by-pass firewalls, you get exactly what you should > get (in many cases, that is sensible service...) People often make the rules wrong (e.g. filter on the outbound interface only). Not IETF's fault though. But my take is, filtering in this kind of scenario is not that commonplace. It should not have to be done in every node (see routing header debate). > | A problem is that one does not know how tunneling is implemented. If one > | receives a packet from a tunnel, does one apply all the same checks one > | would if the packet had come from the wire? > > One certainly should. A tunnel interface is just an interface, the > same as any other - except that by having it (and having it available) > you know that you're admitting packets that other firewalls might not > have noticed, thus you need to use extra care with filtering. I wonder if all implementations do this. > | There are > | other issues, like being able to inject IPv6 packets with hop limit = 255 > | from anywhere in the Internet. > > Huh? if you're forwarding a packet that has been decapsulated from a > tunnel, you certainly better be decrementing the TTL first (even if you're > just forwarding it to a local - internal - interface). The tunnel > is just a link like any other. You wouldn't be forwarding a packet from > ethernet to somewhere else without decrementing its TTL, nor should you > from a tunnel. Sure, if you're physically forwarding the packet, hop limit is decremented. Incoming tunneled packets can arrive via the outbound interface to tunnel interface with hop limit = 255. The spec says the _sender_ decrements hop limit by one, so one can forge packets here. Yhe hop limit is not decremented, if the target node (e.g. the internal interface address) itself receives the packet, IIRC. If it's forwaderded off the node, sure it's decremented. This can be IMO rather dangerous as more and more services are using "hop limit = 255" as an (additional) weak authentication method. Fortunately, at least most services require additional proof, e.g. use of link-local addresses. -- 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] --------------------------------------------------------------------
