On Sat, 1 Sep 2001, Francis Dupont wrote:
> In your previous mail you wrote:
>
> > => this is not true, hosts are not supposed to forward source routed
> > packets to other nodes. Many implementations have a flag which enforces
> > this behavior by default because disabling source route breaks things
> > and enabling forwarding breaks security).
>
> Please read RFC2460 4.4. Nowhere does it say that hosts should not
> forward source-routed packets.
>
> => 4.4 just describes how to process a source route header, it doesn't
> specify if/why a node should process it. This is implementation dependent
> and of course a clever implementer won't blindly forward source routed
> packets. Of course the host requirement document should fix that
> (as RFC 1122 section 3.3.5). A statement like mine is likely to be in it...
> (note that RFC 1122 is applied to IPv6 too for many details, this doesn't
> really replace a real spec but it helps (:-), in your case RFC 1122 should
> be enough, not a surprise...)
All too true. Why would anyone want to comply with the standards anyway?
;-)
> > => this is not true (and AH authenticates routing headers, rewritting
> > doesn't matter because it is predictable).
>
> Ok granted, this can be done, but intermediate nodes should at least check
> for the existance of AH.
>
> => I can't see the benefit because intermediate nodes won't be able to
> verify the AH (authenticated source routing is known to be unfeasible
> with IPsec, just check IPsec mailing list archives).
It cannot be verified, but at least it would ensure the sender is serious
about getting the source-routed packet through. This would avert
implementations that don't require AH to be used for source-routed
packets, not too bright crackers, etc.
But now I agree that this would probably just add unnecessary, imperfect
overhead (at least with the current AH usage guidelines).
> > => host2 should drop the packet on the floor.
>
> No. AFAICS, RFC 2460 8.4 applies only to the end-node, here host3,
> replying to the packet:
>
> => 8.4 is for the final destination. Your issue is with an intermediate
> destination which is a host. If it doesn't forward packets there is no
> problem, isn't it?
Most, and worst problems are avoided, see below.
> > Does disabling routing header break anything significant?
> >
> > => YES, IT DOES!
>
> Please elaborate.
>
> => any device which needs to set the path followed by a packet:
> - mobile IPv6 routing optimization (a case of source route without
> forwarding)
> - some multihoming solutions
> - policy routing
> etc.
One could argue whether IPv6 header is the right place for routing
decisions, rather than the routing system itself. At least when there
aren't secure guidelines on which routers can safely be used as "beacons".
Routing header won't scale to real policy routing, I think (nice way to
test and debugging of course).
All in all, most of these seem to be scenarios where you know beforehand
which routers (or at least, which group of routers) you're going to use as
source-routing hops, right? So negotiating beforehand that source-routing
will be accepted would be acceptable?
> Most ngtrans methods can be used for some kind of DoS attacks; with some,
> you can even disguise yourself pretty well. These are being worked.
>
> => this is more serious issue than source routing, and the fix is
> not easy.
DoS is always possible. It's boring, nasty or really nasty. Really nasty
issues with ngtrans methods are being plugged, I hope, but some nasties
will remain.
In the end, they're only DoS attacks, though. In most cases they cannot
be used to map your internal network, go around firewalls, bounce exploit
traffic off real routers.
Both are important, but source-routing without any controls (esp. if
hosts can forward) is a disaster waiting to happen.
> I haven't taken a look at home address option too deeply, but wasn't it
> just that Mobile IPv6 was put to freeze due to improper security
> considerations?
>
> => no, for improper solution to security considerations (even I personally
> believe more work is needed for the home address option).
Sigh.. I really hoped I wouldn't need to muck with Mobile IPv6, but
perhaps I'll have to look at it... :-/
> PS: is my proposed fix for the future host requirement document enough
> for you? (for other implementors) is it acceptable? is it already what
> you do (or would like to do)?
Linux and AFAICS, KAME at least let hosts act as "reflectors". I'm sure
that's what all would like to do.
Is it enough in the long term? Probably not. As a short term, perhaps
yes.
Issue with the fix is that you can still do nasties, even though _way_
less (as router addresses don't usually have many services which have to
be enabled in site ingress packet filters):
host1 --- rtr1 --- rtr2 --- rtr3 --
\ Big internal topology
\
\-- rtr4 --
Here, you could bounce off with e.g. ICMP echo requests, ICMP PMTU, or
whatever from every site's internal router (even ending to those with e.g.
site-local addresses), and map the network by ICMP unreachables you get
back.
In the long term, I think, this should be all of the below:
0) Rewriting the header based on routing header SHOULD be configurable
(MAY be per-interface).
1) if the behaviour is configurable, on hosts it MUST default to
disallow.
2) if the behaviour is configurable, on routers it SHOULD default to
disallow.
3) if the behaviour is not configurable, on all nodes it MUST default to
disallow.
SHOULD in 2), at least, is debatable. ( 3) would make about all the
existing implementations non-compliant, big deal :-)
--
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]
--------------------------------------------------------------------
