Erik, Let us compare a bit the cases to get more understanding.. I see your point, though would also like to clarify the alternative I was explaining. I was in search of an alternative with minimum change requirement. These are design choices affecting many places so they are worth discussing a bit..
We are here talking of a domain that - does not allow source routing in general, but - allows 1-address source routing if the addresses are in the same node. > > 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. > > My point is that segments left = 1 routing headers can be still used > to hop between two separate nodes. The firewall can't tell the difference > unless it knows all the CoA-HoA relationships for the MNs inside it. My point was that even though firewall would not know, if we have enforcement of the "host-check" rule [cf. Pekka's mail for its decoding], in all nodes _receiving_ the routing header, this would be a distributed way of enforcing the conditions we discuss. > > If reflector scenarios > > need to be avoided in the domain, end nodes need to enforce this. > > But the segments left = 1 routing header could list internal routers > and not end nodes. So just checking on all end hosts inside the firewall > isn't sufficient to prevent any use general use of routing headers. This merits a clarification, partially due to 2460's terminology that has caused some confusion earlier. A firewall who forwards a routing header does not receive it, but merely checks for its existence in the packet. A forwarding source router would be any node that receives the packet, processes the routing header, and forwards it ahead according to the routing header. In the distributed approach I was describing, we would need the "host rule" to be something to enable or disable in forwarding source routers, too. In case source routing would be disabled for the domain, they too would disable 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. > > My point is that the current format is an overloading which makes it > impossible for a firewall to tell the difference between two different > uses of the routing header. I agree, and if the condition we discuss would be enforced locally in a firewall, it would need to know this from the message. > As Pekka's draft points out this could lack of distinction could > be addressed by defining a new type of routing header which is > limited to "forwarding" on the same node. True. This is another way, which is a "cheaper" way than a totally new extension header to have the control localized to the firewall. > > 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? > > No. So to get more clarity, is the localization (to the firewall) of controlling the use of routing header something that you find necessary? If so, would the use of "type 1" routing header in MIPv6 draft address the issue? > Erik 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] --------------------------------------------------------------------
