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.)
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.
Mobile IPv6 implementation complexity increases quite dramatically.
I would just say "... complexity increases."
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].
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.
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?
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:
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.
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?
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).
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?
Jari
_______________________________________________
MEXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mext
