> > 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.
Agree. Besides, in an id/locator split solution, the uRPF can do little help in preventing identifier spoofing, so it's more necessary to strengthen the unspoofability of the identifier. > 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). Why? Can you explain more? Due to the usage of the base exchange? Xiaohu Xu -- 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
