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).
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).
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.
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 :-).
And IPv4 source routing is disabled, luckily, very often.
=> I am against this opinion that suggests to remove all devices which
can give a security issue if misimplemented. This is not really better
than the opposite (cf. active "attachement" discussions).
This won't help:
--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.
More discussion on approaches to tackle this is needed, but IMO:
Forwarding datagrams with Routing Header SHOULD be configurable.
=> I agree, in fact I believe all generic node (i.e. host and router)
implementations have some flags to control this.
On Hosts, Routing Header MUST be ignored by default.
On Routers, Routing Header SHOULD be ignored by default.
(I'd only recommend allowing routing header on in backbone routers)
=> I disagree because of:
Does disabling routing header break anything significant?
=> YES, IT DOES!
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...
Regards
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
