Jari/Wassim/Christian,
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with other Last Call comments
you may receive.
Document: draft-ietf-mipshop-cga-cba-02.txt
Enhanced Route Optimization for Mobile IPv6
Reviewer: Eric Gray
Review Date: 1/30/2007
IETF LC End Date: 1/30/2007
IESG Telechat date: unknown
Summary:
I have a small number of comments and/or questions on this
draft. From a generalist perspective, this is a very well
written and - for the complexity of the protocol involved
- relatively easy to read document.
Comments:
____________________________________________________________________
Security section (2.2), top of page 8, lists ability to "securely
authenticate mobile nodes without preconfigured credentials or a
public-key infrastructure" as an objective of this protocol.
I don't see how it is possible to avoid requiring public keys for
Cryptographically Generated home Addresses - in particular - since
section 3.1 seems to say that CGA results in a binding between each
mobile node's home address and that mobile node's public key, thus
allowing other nodes to securely authenticate the mobile node.
Even though this is done infrequently to establish a semi-permanent
security association, it is done at least once (during establishment
of an initial registration association between a pair of mobile and
correspondent nodes) - hence there seems to be some dependence on
public key infrastructure.
I don't know how to fix this - or even if it needs fixing - but it
might be useful to qualify this "objective" using "ideally". If, on
the other hand, this objective is actually met, I did not see where
this is explained. Is it met, and - if so - is it explained?
____________________________________________________________________
I suggest changing the 2nd paragraph in IANA Considerations to read
something like:
This document allocates the following four new status codes for
Binding Acknowledgment messages:
"Permanent home keygen token unavailable",
"CGA and signature verification failed",
"Permanent home keygen token exists", and
"Non-null home nonce index expected"
The values to be assigned for these status codes must all be
greater than or equal to 128, indicating that the respective
Binding Update message was rejected by the receiving
correspondent node.
____________________________________________________________________
I also suggest that this document should be accompanied with an
explicit RFC Editor's note to replace TBD with IANA assigned
values (as identified by associated parenthetical value names) in
several places throughout the draft. It would help if specific
TBDs were distinct (e.g. TBD-1, TBD-2, TBD-3 and TBD-4) and these
"variable" names then associated (perhaps in a table) with their
meanings in the IANA considerations section.
____________________________________________________________________
Reference 6 ("Cryptographically Generated Addresses (CGA)" - RFC
3972) should be Normative.
____________________________________________________________________
NITs:
====
In the 3rd bullet of section 2.2 (Security), on page 7, it should
be "mobile or correspondent" verses "mobile and correspondent" (more
inclusive as it is probably necessary only to victimize one or the
other to effect a denial of service).
____________________________________________________________________
In the first bullet of the last set of (3) bullets on page 18, it is
really necessary to break this sentence up at least with commas - in
order to make it so a reader can parse it. I suggest:
"If the Binding Update message is complete, the care-of nonce index
is taken from the Care-of Test option or Care-of Test message with
which the care-of keygen token (used to calculate the authenticator
for the Binding Update message) was obtained."
Note that I use parens, rather than commas, to make the structure
more readily apparent.
____________________________________________________________________
In section 6 (Security Considerations), the statement about changes
in the security model - should the reference be [4], rather than -
or in addition to - [1]?
--
Eric
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
