Hi Jari, Thanks for the review. Please see my responses inline:
On 12/30/11 1:52 AM, "ext Jari Arkko" <[email protected]> wrote: >I have reviewed this specification. I think it is in good shape and >almost ready to move forward. I have some comments below, please address >them in a new revision of the draft. My main comments relate to sequence >numbers, Section 7, and IANA considerations. > >> The HAC can be co-located with the HA, or can be an >> independent entity. For the latter case, communication between HAC >> and HA is not defined by this document. The Diameter protocol can be >> used between the HA and HAC when the two entities are not collocated. > >I'd change the last sentence to: "Such communication could be built on >top of AAA protocols such as Diameter, for instance." > >(You can't just use Diameter, you'd have to define a specific way of >doing it.) Okay. In the context of this I-D, I believe it is sufficient to provide an example of the protocol(s) between the HAC and HA. > >> The security framework proposed in this document is not intended to >> replace the currently specified architecture which relies on IPsec >> and IKEv2. It provides an alternative solution which is more optimal >> for certain deployment scenarios. >> > >Add to the end: > >This and other alternative security models have been considered by the >MEXT working group at the IETF, and it has been decided that the >alternative solutions should be published as Experimental RFCs, so that >more implementation and deployment experience with these models can be >gathered. The working group may reconsider the status of the different >models in the future, if it becomes clear that one is superior to the >others. Sure. > >> Mobile IPv6 implementation complexity increases quite dramatically. > >I would just say "... complexity increases." Okay. > >> At an abstract level it can >> be said that implementing Mobile IPv6 with IPsec and IKEv2 is >> possible only with modifications to the IPsec and IKEv2 components. >> The original design intent was to reuse IPsec without having to >> modify them. The current security model requires an IPsec/IKEv2 >> implementation that is specific to Mobile IPv6. > >I don't think this is quite right. I'd reword to: > >Implementing Mobile IPv6 with IPsec and IKEv2 requires modifications to >both the IPsec and IKEv2 components, due to the communication models that >Mobile IPv6 uses and the changing IP addresses. For further details, see >Section 7.1 in [RFC3776]. Okay. > >Section 3 felt a little bit duplicated text from Section 1. Might be an >idea to look at merging the two. Don't spend too much effort on that >however, I can live with the current two sections as well. Will revisit the section and see how best to improve it. > >> Sequence numbers: >> >> A monotonically increasing unsigned sequence number used in all >> protected packets exchanged between the MN and the HA in the same >> direction. Sequence numbers are maintained per direction, so >>each >> SA includes two independent sequence numbers (MN -> HA, HA -> >>MN). >> The initial sequence number for each direction MUST always be set >> to 0 (zero). Sequence numbers cycle to 0 (zero) when increasing >> beyond their maximum defined value. >> > >I don't understand why sequence numbers have to be agreed on between the >MN and HAC. Perhaps the use of sequence numbers should be, not the >numbers themselves? True. Will revise this text. > >Please clarify. > >> form of a Network Access Identifier (NAI) [RFC4282 >><http://tools.ietf.org/html/rfc4282>]. >> >> mn-id = "mn-id" ":" nai CRLF >> nai = username >> | "@" realm >> | username "@" realm >> ... > >I'd prefer you to just say after the first line that "nai" is as defined >in RFC4282, not repeat the definition here. Or if you do repeat it, >please indicate that it is copied here for convenience. Otherwise people >have to go back to RFC 4282 and check that the definition is the same. (I >did that, for instance.) > >You should use ABNF, please respecify the syntax in ABNF. If I take your >syntax and change "|" to "/" I still get at least one error here: We will just reference RFC4282 which would be optimal. > >> >> mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date >> CRLF > >> The HAC SHOULD provision the MN with an UDP port number, where the >>HA >> expects to receive UDP packets. If this parameter is not present, >> > >This comes suddenly for the reader, who at this point has not been >introduced to the change that you run everything on top of UDP. Please >explain this better earlier in the document. Okay. Will do. > >> The SPI value is followed by a 32-bit Sequence Number value that is >> used to identify retransmissions of encrypted messages. Each >> endpoint in the security association maintains two "current" >>Sequence >> Numbers: the next one to be used for a packet it initiates and the >> next one it expects to see in a packet from the other end. If the >>MN >> and the HA ends initiate very different numbers of messages, the >> Sequence Numbers in the two directions can be very different. In a >> case encryption is not used, the Sequence Number MUST be set to 0 >> (zero). > >It seems odd to use sequence numbers only for encrypted packets. What >about integrity protected packets? Good questionŠ Need to rethink why this was designed as such. Will come back with an answer. > >> All >> packets that are specific to the Mobile IPv6 protocol and contain a >> Mobility Header (as defined inSection 6.1.1 >><http://tools.ietf.org/html/draft-ietf-mext-mip6-tls-02#section-6.1.1>. >>ofRFC 6275 <http://tools.ietf.org/html/rfc6275>) SHOULD use >> the packet format shown in Figure 7. (This means that some Mobile >> IPv6 mobility management messages, such as the HoTI message, as >> treated as data packets and using encapsulation described in >> Section 6.4 >><http://tools.ietf.org/html/draft-ietf-mext-mip6-tls-02#section-6.4>). > >This seems like an inconsistency. HOTI messages are MH messages. Which >format do you require for them? Please ciarify. > >Section 7 seems odd. First, you say that you don't cover the RO part and >then you go on explaining nice ideas that could be done. I would replace >Section 7 with the following information: > >- statement that this specification does not change any of the procedures >for RO >- explanation that tells the reader how the TLS-based HA security model >can still support the existing RO procedures (and if it can not... I >think you'd have to change your spec... but I don't see why it would have >problems). >- identification of possible gaps for future work, such as supporting RO >to IPv4 destinations (but we don't support that today, so this isn't the >fault of your document). But do not include extra new ideas that could be >done (like HAC-based RO). Agreed. Will make this change. > >IANA considerations seems to need some material for the attributes used >in your new protocol. Who can allocate them, and should there be a >registry? Will beef up this section further and propose a registry if needed (not sure if that is the case yet). -Basavaraj > >Jari > >_______________________________________________ >MEXT mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/mext
