Pekka Savola wrote: > > On Sun, 9 Dec 2001, Jari T. Malinen wrote: > > I have some doubt on this being better. How I would understand this issue > > to apply is when a firewall e.g. would like to enforce: don't let source > > routed packets through but only packets with both addresses in the same > > end-host. > > > > Though the firewall can't know CoA-HAddr associations, it might not > > want to enforce these packets only to concern MNs. The same reflector > > attacks could also be done using non-MN hosts. When enforcing the above > > example firewall policy, maybe it could be less change-requiring to > > recommend the host-check rule also for non-MN's (CNs). Then, a firewall > > would allow only rthdrs with segments left 1 through. If reflector scenarios > > need to be avoided in the domain, end nodes need to enforce this. This because > > also tunneling to an end host can be made to reflect the inner packet to > > another host. Hence, a format change in a protocol may not be what is > > needed to address this issue, a rule in one form or another in the > > end hosts might be needed anyway. Inventing a new format could make the > > rule look implicit, though it needs to be enforced anyway in an > > implementation. > > > > Comparing to having a new message format, all hosts using it would > > anyway need to implement the new format. The host rule for rthdr would > > have the same scope of implementation change but with existing protocol > > messages, and the change would only be an added check in implementation > > of existing protocols, without protocol specification. Does this address > > the issue? > > The problem here is that a random CN host does *not* *have to* enable > routing header processing at all -- and is therefore not affected. With > current mechanisms, a random CN does not have a need for implementing > "interface-local" routing headers, but it could be done nonetheless.
True, CN does not need to support interface-local routing headers. However, when CN supports routing headers, there is currently no distinction whether they are interface local or not. But as you say, when no routing header support is there, there is no problem. > On the other hand, MN *must* enable routing header processing. As > currently specified, this opens the host to the attacks specified in my > draft. The has to be some control on what routing headers to accept, more > fine-grained than on/off. To clarify, with host-check rule I was refering to the condition you describe below, not just turning routing header processing on/off in MNs. > Another possible heuristic for accepting routing header could be: > > if segments left == 1 > if the address to be swapped is a home address > accept routing header > fi > else if routing header processing is enabled > accept > else > reject > fi > > This would be more MIPv6-centric and possibly easier to implement. I > don't know if there is need for "generic" use of interface-local routing > headers outside of MIPv6 context at the moment. Agreed. > -- > 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 BR, -Jari -------------------------------------------------------------------- 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] --------------------------------------------------------------------
