Tony -
More precisely: in a loc/id solution, just filtering on the id is insufficient. One can emulate the previous (insecure) semantics by filtering on the (loc, id) tuple.
Filtering on locators alone, even in a locator/ID split solution, would actually be sufficient to emulate return-routability-flavor security. There is no extra benefit in additionally including the ID in the filter unless the ID was unspoofable. However, if the ID was unspoofable, then there would be no reason to include the locator in the filter. It goes back to what you were saying earlier: Any remote information can be reliably filtered upon if and only if it is unspoofable. Highly desirable would, of course, be a solution that allows filtering exclusively based on IDs. The benefits would be easier mobility and multi-homing support, as well as simpler renumbering. Yet finding a solution that enables such filtering in a secure way is hard. Worthwhile to note: By "unspoofable" above I mean securely verifiable on a per-packet basis. This is substantially harder than host-to-host verifiability. E.g., a HIP host identity tag is cryptographically verifiable by the communicating hosts, but it cannot be securely verified by filters (or other middleboxes). - Christian -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
