Thanks Ben for a thorough review. Very good comments indeed. We'll come back
to this in a bit.. you know -00 deadline approaching and such ;)
- Jouni
On 2/29/12 1:34 AM, "ext Ben Campbell" <ben(_at_)nostrum(_dot_)com> wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-mext-mip6-tls-03
Reviewer: Ben Campbell
Review Date: 2012-02-28
IETF LC End Date: 2012-02-29
IESG Telechat date: 2012-03-01
Note: Since the Telechat review deadline is a day before the end of the IETF
last call, this review serves both as a Telechat review and an IETF Last Call
review.
Summary: This draft is basically ready for publication as an experimental RFC.
There are some clarification issues that might should be addressed prior to
publication.
Major issues:
None
Minor issues:
-- general:
The draft seems to be missing information on how to match TLS certificates to
identities for HAC authentication.
-- section 1, paragraph 1, last sentence: "Client implementation experience
has shown that the use of IKE(v2)/IPsec with Mobile IPv6 is fairly complex."
It might be worth elaborating on why this is true. Could this be solved with a
cleaner software architecture rather than a protocol change?
-- section 5.4: "The actual domain name used in queries is up to the
deployment to decide and out of scope of this specification."
This seems under specified for SRV
-- 5.7.4:
Are more than one DNS server allowed for each protocol?
-- 5.8:
I find this section confusing,as the first and second paragraphs seem to make
contradictory statements about the authentication, particularly about the use
of PSK. I think you are talking about authentication of the HAC in the TLS
handshake vs an higher level authentication of the MN using PSK or EAP. I
think this could use some clarification, as both paragraphs talks about
authentication between the MN and HAC without mentioning direction.
Note that this is more clear in the security considerations section, but it
would help for it to be more clear here.
-- 5.9, 2nd to last paragraph:
How do the first and last sentences relate? It seems to say set it to "1",
except for this case in which you set it to "1".
-- 8.1:
Is this registry only for TLS based MIPv6? If so, does it need to be
explicitly constrained to not used for MIPv6 in general?
Nits/editorial comments:
-- section 4.1:
A picture showing the element and key relationships could be helpful here.
-- section 4.3, third paragraph:
Please expand BA on first mention
--section 4.3, "Security association validity times", : "hours or weeks"
Hours _to_ weeks?
-- section 4.3, "selected cyphersuite": " The selected algorithms SHOULD be
one of the mutually supported ciphersuites"
How could it be otherwise? (i.e. why the SHOULD, and is this really normative
vs descriptive?)
-- section 4.4: "Home Agent IP Address" : "Concerns both IPv6 and IPv4 home
agent addresses."
Dual stack only? (same applies to "Home Address" section)
-- section 5.1, second paragraph: "All data inside the Content portion of the
message container MUST be encoded using octets."
I suspect I'm missing a subtlety here--but how else could you do it? Is this
intended to imply a byte-field, or to imply no additional encoding is used?
-- section 5.2: "From now on, we use TypeValue header (TV-header) term to
refer request-response message content HTTP-like headers."
Maybe that should be moved to the terminology section?
-- section 5.3, 2nd paragraph: "The MN is also the peer that always sends only
request messages and the HAC only sends response messages."
I'm having trouble parsing. Is their a spurious "always"?
-- section 5.5 : "same to that used by HTTP"
same _as_?
-- section 5.5.5
s/till/until
-- 5.5.8, 1st sentence:
Sentence fragment. Missing words?
-- 5.9, first paragraph:
Sentence fragment.
-- 5.9, 2nd to last paragraph:
s/"In case the"/"In the case that the"
-- 9:
A general discussion of threats would be helpful. Some aspects are scattered
in the subsections, but a summary in one place would be nice.
-- 9.2:
It's not clear to me if the text in the "Dictionary Attack" section is
actually related to dictionary attacks.
-- 6.1:
A picture of the general packet format would be nice. You've got them later
for specific packet types, but no "general" picture.
--6.2:
Section seems mostly redundant to 6.1
-- 6.3:
Please expand HoTI on first use.
-- 7:
Please expand CoTI/CoT on first use
-- 8.3:
I'm not sure I understand the mnemonic relevance of "HALTSEC"
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf