On Sat, 1 Sep 2001, Francis Dupont wrote:
> In your previous mail you wrote:
>
> RFC2460 (The IPv6 Spec) assumes that all _nodes_ (note not routers)
> forward source routed packets.
>
> => 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. E.g.:
If, after processing a Routing header of a received packet, an
intermediate node determines that the packet is to be forwarded onto
a link whose link MTU is less than the size of the packet, the node
must discard the packet and send an ICMP Packet Too Big message to
the packet's Source Address.
[...]
note 'node' not 'router'; also forward 'forward'.
> Routing header works so that the next hop is always written to destination
> address field and the rest of the path to routing header fields.
>
> Problem with this is that:
> 1) it's impossible to authenticate using AH or the like as the header is
> rewritten all the time
>
> => 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.
> 2) it allows you to use _any_ IPv6 node to reflect your traffic (, even
> to locations that wouldn't normally be routable)
>
> => this is not true if RFC 2460 section 8.4 is correctly implemented.
>
> For example: or even:
>
> host1 --- rtr1 - INET - rtr2 --- host2 - rtr2 --- host2
> | / |
> rtr3 -/ host3
> |
> host3
> or even (same link):
>
> - rtr2 -+- host2
> |
> +- host3
>
> rtr2 performs strict ingress filtering on tcp destination port 80. host2
> is a web server. (IMO, we _cannot_ assume every device in the path must
> be knowledgeable of all the possible extension headers, and implications
> of parsing them).
>
> Now host1 could write a packet to dst host2, dport 80, with routing header
> to: 'rtr3, host3' (or even just 'host3', there need not necessarily be
> rtr3). (To avoid this, you would have to perform strict ingress filtering
> in _all_ of your links, be they internal or not).
>
> Now you can pass traffic unmolested to internal hosts. Or even John Doe
> in the Internet!
>
> => 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:
When an upper-layer protocol sends one or more packets in response to
a received packet that included a Routing header, the response
[...]
Response in my book means the final endpoint, not a router or host
forwarding the packet to the next hop.
Please also note:
When an upper-layer protocol sends one or more packets in response to
a received packet that included a Routing header, the response
packet(s) must not include a Routing header that was automatically
derived by "reversing" the received Routing [...]
forwarders don't reverse the order for their "responses" (which aren't
responses as meant here) (unless they send out some ICMP6 messages, but
that's a different story), which implies that response is one sent by the
final destination.
Thus here, if there is no AH, the packet could go:
packet: host1 -> rtr1 -> ... -> rtr2 -> host2 -> rtr3 -> host3 (with
routing header)
response packet: host3 -> rtr3 -> rtr2 -> ... -> rtr1 -> host1 (without
routing header)
The defenses have been penetrated in this scenario; the return traffic can
flow in asymmetric fashion.
> There is no reason to believe IPv6 Routing Header is any better from
> security point of view than IPv4 source routing.
>
> => I disagree, read RFC 2460 section 8.4 (or better, ask your implementors
> to apply it :-).
Please read it again keeping in mind what 'response' means.
> --8<--
> Security Considerations
>
> The security features of IPv6 are described in the Security
> Architecture for the Internet Protocol [RFC-2401].
> --8<--
>
> At this point one could say a classic "WTF? Over." With this important
> core protocols, we definitely _must not_ hide _all_ the security
> considerations under the carpet by ambiguous reference to the ipsec
> security pixie dust.
>
> => I disagree (again). The security features of IPv6 are simply IPsec.
One can not say there aren't security considerations to the routing header
use. IPSec can help with them, but unless they're identified, it's just
some "magic" that may give a warm fuzzy feeling.
> Does disabling routing header break anything significant?
>
> => YES, IT DOES!
Please elaborate. Something related to Mobile IPv6? They should be using
AH anyway.
> If it does, the security of that must be analyzed as well.
>
> => it was and it will be but the security argument should be applied
> against two address pseudo-firewalls, not against source routing.
> And if you need something to have nightmares this night, just look at
> the home address option (same property than a one address source route,
> but on the source address in place of the destination) or tunnelling,
> esp. ngtrans devices which can hide both the real source and destionation
> addresses without trails...
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, on the other hand, gives the malicious party an active and really
configurable to option to really work around even best defenses.
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? <shrug>
--
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]
--------------------------------------------------------------------
