> 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.
Sorry, I can't seem to parse the above paragraph. > 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. > 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 > 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. 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. > 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. Erik -------------------------------------------------------------------- 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] --------------------------------------------------------------------
