Let's have some discussion on this review.
RFC 3012 is widely implemented in cdma2000 networks and this
update provides some (in my opinion) much needed, but somewhat
minor, clarifications to the handling of the challenge values
to provide for greater interoperability between MNs and FAs.
I do not think we should give up on it lightly.
I hope during our discussion we can stick to specific text in the
document and avoid blanket generalizations.
From the review:
> One comment from the mdir was that this document describes two
> protocols
> (the CHAP stuff and the AAA stuff). The usage of phrases such as
> 'updates RFC3344 by including new authentication extension' in a
> paragraph added to the abstract gives the impression that an extra
> protocol has been added: in fact, this isn't the case. No new
> protocol
> or extensions have been added since 3012 - just clarifications of
> operation. So I would go through the document and remove all the
> 'new'
> words. They weren't new before this document and they certainly
> aren't
> new now.
As a bis document, I for one think it is appropriate to keep
the "new" terms from the original, in the interest of consistency.
The reader of this bis document should understand that "new"
means "new relative to the base Mobile IPv4 specification."
As for the added paragraph, maybe it would be better just to
say "This document updates RFC 3344 and obsoletes RFC 3012."
> As regards separating out the two parts, this might simplify
> some parts: The wg would have to determine if the work needed is
> justified for either part.
We discussed this but decided splitting was unnecessary at this
time, again, for consistency with RFC 3012.
> A few points which jumped out at me:
> Abstract: too long.
Shortening the added paragraph to 1 sentence as outlined above
may help with this. We could even combine all 3 paragraphs
back together again.
> s2 and s2.1 may conflict: s2 says the challenge must be previously
> unused but s2.1 says a multicast advert should reuse the latest
> challenge with no quailifications on status.
I think the expectation was that the last challenge would in
most cases also be previously unused. We can add an explicit
qualification here that if the latest challenge value is
previously used by any MS then the FA needs to generate a
new one.
> There is no motivation
> for
> why the challenge should be reused... It is possible that this is on
> account of the extra piece in the security considerations about DoS
> attacks but something should be said here.
Yes, the idea is that we shouldn't be modifying the FA state
based on unauthenticated messages from the MS. The definition
of "previously used" was carefully constructed to make sure
that using a challenge also involves authentication of the MS.
> s2.1: . CHALLENGE WINDOW hasn't been defined when it is used here
It is a simple numeric constant defined in Section 9, and we
have an explicit reference to it. I don't think it causes
too much confusion.
> s3.1: First para has been added in update: why do we now go straight
> to
> retransmission? we don't know what is being transmitted yet!!
It may be a good idea to move this paragraph to the end of
Section 3.1.
> ss3.1-3.4: The way in which the logic is written down here made my
> brain
> hurt. Surely there must be a better way to express all this! The
> added
> pieces in s6 are just as bad.
Can you be more specific here? The text looks ok to me.
> s8: The end of the last paragraph may or may not make sense, but there
> is *surely* a better way of saying it:
> Finally, the least significant 237 bytes of the challenge
> are concatenated. If the challenge has fewer than 238 bytes, this
> algorithm includes the high-order byte in the computation twice,
> but
> ensures that the challenge is used exactly as is. Additional
> padding
> is never used to increase the length of the challenge; the input
> data
> is allowed to be shorter than 237 bytes long.
> The last two sentences were added in the update and I really don't
> think
> they helped!
This was a critical piece of clarifying text that we added because
the existing text left an ambiguity and there were conflicting
implementations. In particular some implementations left out
the high-order byte because it was already included earlier
in the computation. Maybe a better way to say it would be to
replace the two sentences with:
If the challenge has fewer
than 238 bytes, then all of the bytes, including the high-order
byte, are included in the field labeled "Least-order
237 bytes from Challenge" with no padding.
What do you think?
-Pete
Brian E Carpenter wrote:
Please copy Elwyn too. (He is on travel with some connectivity issues,
I believe, today.)
Henrik Levkowetz wrote:
Hi, both Jayshree and WG:
I'm forwarding a Gen-ART review summary of 3012bis, with a link to
the full
summary. This is pretty serious, and I think both the Editor and
the working
group needs to consider once more whether this document is ready, or
whether
a rather more serious re-working is needed.
Regards,
Henrik
-------- Original Message --------
Subject: COMMENT: draft-ietf-mip4-rfc3012bis
Date: Thu, 16 Feb 2006 04:21:55 -0500
From: Brian Carpenter <brc at zurich.ibm.com>
To: iesg at ietf.org
CC: mccap at lucent.com, henrik at levkowetz.com
Comment:
The Gen-ART review from Elwyn Davies cuts very deep so like Sam, I
will abstain.
Summary of the review:
...this draft needs considerably more work to be a useful PS. There
has to be some doubt, given the use of CHAP, whether it is *worth*
devoting too much effort to it, but that is a decision for others.
The overall impression that comes over from the document is a
hurried attempt to patch up a crumbling edifice that maybe ought to
be demolished and rebuilt differently. The convoluted logic
described and the fact that it is extensions to, combinations of or
realignments of about three other protocols makes it extremely
difficult to see whether the whole thing could be correct - the
additions since RFC3012 appear to be attempts to fix something that
was pretty broken!
Full review (actually of the previous version, but still applicable);
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-mip4-rfc3012bis-04-davies.txt
