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...)
> => 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).
> => 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?
> 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.
Something related to Mobile IPv6? They should be using AH anyway.
=> no, mobile IPv6 doesn't mandate AH for every packets!
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.
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).
Regards
[EMAIL PROTECTED]
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)?
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
