JJ Behrens wrote: > Sir, > > You are correct, and this in mentioned on the last paragraph > of page 5: > > Of course, if Alice implements the "strong" exchange, a very valid > policy would be for it not to engage any more in "weak" exchanges. > This simplifies Alice's protocol processing and is more secure > because Alice avoids any risk of falling victim to a bidding down > attack. For a mobile node, this translates to requiring a "strong" > mechanism for route optimization. The mobile node simply > forgoes the > benefits of route optimization and limits itself to > bidirectional... > > However, I think a more important point is written in the > last paragraph of > page 3: > > For an unsuspecting stationary node that is not interested in > redirecting its address, (3) may not be a viable tradeoff. It > essentially means that the node only obtains the negative > side of the > tradeoff (it becomes a potential victim of the vulnerabilities in > RR), as it is not at all interested in the benefit (route > optimization of its addresses). > > Of course, I'm still in the process of reading the draft, so > I may be wrong. >
Actually your response reminds me of the comment I intended to make earlier. This draft really gets lost in the concept of MN/CN, & Stationary/Mobile. Nothing personal intended, but I suspect this is due to the perspective of the contributers. The terms Stationary & Mobile have no business being in the document since they are related to physical properties of the device, not the header properties of the packets emanating from them. All the points made about a Stationary node would apply just as well to a Mobile who happened to be at home, and all the points about the Mobile device could be used by Stationary that had reason to use a BU to manage associtations across address changes. The terms that might have a more consistent interpretation are; 'intends to use secure MIPv6', or 'does not intend to use secure MIPv6'. Physical properties of the device are not wrapped up in those. The relationship of MN to CN is unidirectional. There may be an inverted pair of those relationships for a connection, but there is no requirement that a pair exists or explicitly does not exist. What should be clear is that policies applied to each of those unidirectional relationships must remain independent. If Alice wants Bob to state intent about using secure MIPv6, a real protocol is required. Trying to overload the semantics of Alice telling Bob that she will be using secure MIPv6 (particularly through a single bit) as a message that Bob must reciprocate is fundamentally flawed. What if Bob had no means to use secure MIPv6? How can Alice tell that condition from Mallory sitting in the middle? What is to prevent Mallory from doing a double address NAT thing where its own IID ends up being presented to Alice and Bob along with appropriate credentials? The address is simply the wrong place to put a single bit flag that really accomplishes nothing in the end. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
