Subject: [Mip4] [Fwd: COMMENT: draft-ietf-mip4-rfc3012bis]

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 16 Feb 2006 11:41:39 +0100

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 <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]

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

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Feb 2006 14:07:58 +0100

Please copy Elwyn too. (He is on travel with some connectivity issues,
I believe, today.)

---

From: Pete McCann <[email-masked]>
Date: Tue, 21 Feb 2006 11:34:30 -0600

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:
>> ...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!

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 21 Feb 2006 10:23:24 -0800

Hello Pete,

I agree with all of your suggestions, and think we should proceed
to resolve the issues that have been raised along the lines that

> previously used by any MS then the FA needs to generate a

The same challenge could reasonably be used by several mobile
devices.  It might be too much to immediately generate a new
challenge and advertise it right away just because the current
one has been used in a registration.  The main thing is to prevent
the same mobile node from using the same challenge twice.

In general, isn't is to be expected that we should try to revise
Proposed Standard protocol documents in light of experience
gained by deployments?

Regards,
Charlie P.

Pete McCann wrote:

>>> 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!

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Feb 2006 15:06:06 +0100

> I do not think we should give up on it lightly.

That's exactly why I recorded an Abstain ballot, to express
reservations but without automatically blocking progress.

Please take guidance from Margaret on what changes to make.

     Brian

---

From: Pete McCann <[email-masked]>
Date: Mon, 27 Feb 2006 09:38:32 -0600

Hi, Charles,

> the same mobile node from using the same challenge twice.

That makes sense, but then I think we need to change this text
from section 2:

    The Challenge extension, illustrated in Figure 1, is inserted in the
    Agent Advertisements by the foreign agent, in order to communicate a
    previously unused challenge value that can be used by the mobile node
    to compute an authentication for its next registration request
    message.

To remove the "previously unused".  We can just say "in order
to communicate a challenge value".

> Proposed Standard protocol documents in light of experience

Indeed, and I think we should move ahead with some of these
minor changes incorporated.

-Pete