Ted Hardie (IESG) writes: A couple of editorial nits, and three notes, cc'ed only to Thomas, so as not to clutter the IESG list with efforts-to-educate-the-newcomer. Nits: The Introduction says it illustrates the use of IPsec in securing control traffic; Section 3.4 describes the use of IPsec in protecting payload packets tunneled to the home agent. Since these can be "any protocol", they are probably not limiting this to control traffic. "It is important for the home agent to verify that the care-of address has not been tampered." seems to be missing a with" "Where is an boolean expression" should be "a boolean expression". Notes: I was surprised that the manual configuration for security associations were MUST and IKE only MAY. I assume that there is lots of history here, and I don't want to draw anyone into it, but I was surprised. In section 4.3, I was surprised that the instructions on using integrity protection with the manually configured SA did not have a "as of this writing FOO would be the best choice", since it was willing to toss DES. I'm guessing that this means different folks have different flavor preferences here. Section 7's implementation considerations on fragmentation in the presence of certificates surprised me by recommending replacing firewalls or routers, given that we're talking about mobility. Replacing gear in someone else's network is a good trick. -------------------- Jari Arkko responds to IESG: > The Introduction says it illustrates the use of IPsec > in securing control traffic; Section 3.4 describes the > use of IPsec in protecting payload packets tunneled to > the home agent. Since these can be "any protocol", > they are probably not limiting this to control traffic. Yes. This has now been reformulated: "This document illustrates the use of IPsec in securing Mobile IPv6 [8] traffic between mobile nodes and home agents." > "It is important for the home agent to verify that the care-of address > has not been tampered." seems to be missing a with" Corrected. > "Where is an boolean expression" should be > "a boolean expression". Corrected. > Notes: > > I was surprised that the manual configuration for security > associations were MUST and IKE only MAY. I assume that > there is lots of history here, and I don't want to draw anyone into > it, but I was surprised. You are not the only one. There are quite different opinions about the keyword for IKE. Actually we received an earlier comment on this from Steve, I think, and our intention is to produce at least some text that describes the effects and tradeoffs involved. This is being debated under issue #282 so I'll leave further discussion there. (http://www.piuha.net/~jarkko/publications/mipv6/issues/issue282.txt) > In section 4.3, I was surprised that the instructions on using > integrity protection with the manually configured SA did not > have a "as of this writing FOO would be the best choice", since > it was willing to toss DES. I'm guessing that this means > different folks have different flavor preferences here. Yes it means, but not so much in terms of wishing to have different algorithms. The question was mainly about whether its right for this type of a document to specify algorithms. We *had* to do it for DES because the current IPsec RFCs are broken in this sense (and how many years is it since this has been so? we need to deprecate bad algorithms faster). For the other algorithms, we didn't agree on the list. Some folks wanted to specify everything for better intoperability. Others felt that such things could not be done in Mobile IP, and should have been done in IPsec WG. In any case, I'm glad if the IESG thinks we should specify a default, mandatory integrity protection algorithm. Lets do that. See the new document, Section 4.3. > Section 7's implementation considerations on fragmentation > in the presence of certificates surprised me by recommending > replacing firewalls or routers, given that we're talking about > mobility. Replacing gear in someone else's network is a good > trick. Ok. Reformulated to: Fortunately, typical Mobile IPv6 deployment uses short certificate chains, as the mobile node is communicating directly with its home network. Where the problem appears, it may be difficult (at least away from home) to replace the firewalls or routers with equipment that can properly support fragments. It may help to store the peer certificates locally, or to obtain them through other means. -------------------- Ted Hardie responds to Jari Arkko: > In any case, I'm glad if the IESG thinks we should specify > a default, mandatory integrity protection algorithm. Lets > do that. See the new document, Section 4.3. I actually didn't mean for my registering surprise to imply that you had to do that, and I'd suggest getting confirmation from Russ and Steve as well as discussion in your working group before making a change of that magnitude. -------------------- Jari Arkko responds to Ted Hardie: > I actually didn't mean for my registering surprise to imply > that you had to do that, and I'd suggest getting confirmation > from Russ and Steve as well as discussion in your working > group before making a change of that magnitude. I'm sorry, my mistake to misinterpret the nature of the comments. Steve hasn't demanded this so far, and it wasn't clear agreement on WG list earlier when this was discussed -- I'll just roll this particular change back. -------------------- -------------------- --------------------