Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-mipshop-fmipv6-rfc4068bis-06

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 25 Mar 2008 19:49:51 -0400

Hi Ben,

Thank you for your detailed review. See my replies inline.

From: Ben Campbell <[email-masked]>
Date: Sat, Mar 15, 2008 at 4:08 PM
Subject: Gen-ART LC review of draft-ietf-mipshop-fmipv6-rfc4068bis-06
To: [email-masked]
Cc: [email-masked], [email-masked],
[email-masked], [email-masked]

Document: draft-ietf-mipshop-fmipv6-rfc4068bis-06
Reviewer: Ben Campbell
Review Date:  2008-3-15
IETF LC End Date: 2008-3-15

Summary: This document is on the right track, but needs work.

Comments:

Disclaimer: I do not have much background in Mobile IPv6. I assume
others have reviewed this for technical correctness.

--General Comments

This is a difficult review, as the document is an update to a previous
RFC. It is almost certain that some of my comments apply to the
original RFC, and I realize that the goal of this revision is probably
not to fix _every_ issue in that RFC. Therefore, a response to the
effect of "That issue was in the original RFC, and was beyond the
scope of our changes" is perfectly reasonable for most of my comments.

That being said, there are a large number of editorial nits that have
clearly been introduced in this draft that were not in the original
RFC. The omission of articles and incorrect use of "an" vs "a" occur
throughout. A diff shows that there are several paragraphs where the
introduction of such errors are the _only_ changes from the RFC, which
I suspect they may be the result of regression errors. Is it possible
that the author started from the original test for RFC 4068 _before_
the RFC editor edits? If so, I am concerned that if there were any
substantive changes introduced to RFC 4068 during the RFC Editor or
author's 48 process, they  may have been lost. Checking for such
losses would, unfortunately, require more time than I can commit to
this review.

Rajeev:> I will check.

I find the general organization of this document hard to follow. The
general operation of the protocol is described no less than 3 times.
Section 3.1 gives a high level overview. 3.2 gives the same
description in more detail with some more normative language. Section
4 describes it in even more detail with more normative language. It is
common to have an overview section and a detailed operation section,
but I am confused by the presence of the "middle" description.
Normative language is spread across the sections, which increases the
odds of implementation errors.

Section 3 is Protocol Overview and Section 4 is Protocol Details.

Section 3 is split into two subsections - Addressing Handover Latency,
which provides a high-level description of where the delays are and what
the protocol does about, and Protocol Operation subsection, which
describes the high-level operation.

I read through all three descriptions, and still found myself
wondering about basic questions such as "what transport do these
messages use?" It wasn't until section 6 that I learned that some of
the messages are ICMPv6 extensions, and that some of Mobile IPv6
extensions.

Right, the Message Format section defines the transport types.

Finally, there is a great deal of imprecise language that I think
could impact interoperability. There are a number of statements of the
form "an XXX message is sent" or "XXX/YYY messages are exchanged" that
left me digging to figure out what device sends the message and what
device consumes it. I will address some of these in the detailed
comments, but I'm sure there are a number that I missed.

Hmm.. I will look for them below. 

-- Detailed Comments:

Section 2, RFC 2119 boilerplate:

IDNITS does not like the 2119 boilerplate. I don't think 2119 defines
"silently ignore".

Ok.

Section 2, Figure 1:

Do you intend Figure 1 to be part of the terminology section? It might
make more sense to put it nearer the first reference.

Ok, I will consider.

3.1, paragraph 4:

"The information provided in the PrRtAdv message can be used even when

   DHCP [rfc3315] is used to configure an NCoA on the NAR's link.  In
   this case, the protocol supports forwarding using PCoA, and the MN
   performs DHCP once it attaches to the NAR's link.  The MN still
   formulates an NCoA for FBU processing; however, it MUST NOT send
   packets using this NCoA."

The "this NCoA" in the last sentence is assumed to be different than
the one received via DHCP, right?

Yes.

paragraph 5. last sentence:

"Otherwise, it should send it immediately
   after detecting attachment to NAR."

I found the multiple use of "it" to cause pronoun confusion.

Ah, I can rephrase to "Otherwise it should the FBU immediately.."

"And,
   PAR SHOULD forward the inner packet in the tunnel to its destination
   (i.e., to the MN's correspondent)."

Is SHOULD strong enough for this requirement? What happens if the PAR
does not forward the inner packet?

If it doesn't, the packet does not reach the CN. I am okay for a
stronger requirement even though I think PAR will almost certainly
forward it (in this case to provide the fast handover support)

paragraph 7:

"In addition, buffering for handover traffic may be
   desirable."

Buffering by which device? (NAR or PAR?)

This is in the context of discussing NAR's functions. I can make it
explicit.

last paragraph"

"The
   access routers MUST have necessary security association established
   by means outside the scope of this document."

The document should at least describe the security characteristics
expected for such security associations, if it is not going to specify
the mechanisms. (Does this conflict with statements about IPSec in the
security considerations section?)

The document does not specify how SA is established. That's for a
companion document - draft-ietf-mipshop-handover-key-03.txt. Yes, this
document does describe in details what is expected, SPD/SAD entries etc
in Section 9.

3.2, paragraph 1"

"The protocol begins when a MN sends RtSolPr to its access router..."

Which access router? PAR or NAR? Please be specific.

Whichever happens to be the access router. I think we refrained from
using PAR/NAR everywhere because we had considered handovers in tandem
where a MN can go from PAR to NAR to another AR. So, it could do RtSolPr
with NAR when NAR happens to be its access router.

paragraph 2:

" With the information provided in the PrRtAdv message, the MN
   formulates a prospective NCoA and sends an FBU message."

To where? Please be specific.

Ok. To PAR.

paragraph 3:

" Depending on whether an FBack is received or not on the previous
   link, which clearly depends on whether FBU was sent in the first
   place, there are two modes of operation."

I found this confusing, as there are clearly other reasons for not
receiving an FBack than having simply not sent an FBU.

Sure, FBack itself may be lost. But the MN cannot receive an FBack
unless it has sent an FBU.

numbered item 1:

"...PAR can determine whether NCoA is
      acceptable to NAR through the exchange of HI and HAck messages.
      When assigned addressing (i.e., addresses are assigned by the
      router) is used, the proposed NCoA in FBU is carried in HI, and
      NAR MAY assign the proposed NCoA.Z"

Please be specific about which devices sends the and receives the HI.
Same for the HAck. I can infer the answers, but don't just assume the
answers are obvious.

This sender and receiver for these messages are clear for someone with
background in this space. Nevertheless, this comes along fairly early in
the document. So, I will revise it.

numbered item 2:

'Hence, the MN (re)sends FBU
      immediately after sending the UNA message."

Does the MN resend to the PAR or to the NAR?

FBU is always sent to the PAR. 

paragraph 8:

Can you move figures 2 and 3 closer to the first reference? (At least
in the same section?)

Okay.

Section 3.3, Figure 2:

Does the PAR really send the FBack to both the MN and the NAR?

Yes.

Figure 3:

Combining the HI and HAck on same line obfuscates which device is the
sender and recipient for each message.

I see. Will revise.

Section 4, paragraph 2:

"...the MN sends
   RtSolPr in order to resolve access point identifiers to subnet
router
   information."

Sends it where? Yes, the figure shows this--but it's clearer if the
text says it too.

This should also be fairly evident. Will mention at the first reference.

"Implementations SHOULD make use of such
   triggers whenever available."

Is SHOULD strong enough here? If the MN does not have some mechanism
to detect access point changes, how could it use this protocol at all?

It can respond when it gets a Router Advertisement.

paragraph 5 (list item 1)

"...it responds indicating that the new access point is
      unknown."

How is this indicated? That is, what code, option, etc?

This is specified under each message format (see Section 6.1.2). IMO
this is a matter of style.

paragraph 6 (list item 2)

"PAR responds with a Code
      value indicating that the new access point is connected to the
      current interface..."

What is the specific code value?

See Section 6.1.2

Paragraph 7 (list item 3)

"...then PAR responds indicating that the new access point
      is known..."

How is this indicated?

Code values, section 6.1.2

paragraph 15 (list item 3)

"MAY create a host route entry for PCoA..."

Is MAY strong enough? Are there negative consequences of not doing it?

It is an option. Hence the MAY.

paragraph 16 (list item 4)

"provides the status of handover request in Handover Acknowledge
      (HAck) message."

To where does it send the HAck?

to PAR.

"However, it SHOULD be prepared to process any other options which may
   be defined in the future."

What does that mean? How can it process an option that has not yet
been defined? The wording seems to imply more than simply ignoring
unknown options.

I think this sentence should be deleted.

paragraph 25 (list item 1):

"updates
      the state to STALE"

This is the first mention of a formal state--can you reference where
it is defined?

Okay.

Paragraph 26 (list item 2)

Same as previous comment for "INCOMPLETE" state.

Okay.

Paragraph 29 (list item 1)

Numbered list with just one item.

Section 5.4, last paragraph

"... it SHOULD also provide
   its own support for buffering."

Can you provide guidance on how much buffering is needed?

Depends on the implementation. We discussed this and arrived at not
specifying a number.

Section 5.5, first paragraph:

I'm confused. You seem to say that this protocol (I assume "this"
means the protocol being defined) SHOULD only be deployed when there
is little chance of collision--but it also must use DAD to try to
avoid collisions, unless there is little chance of collision in which
case it may turn DAD off. That  seems self-contradictory.

Where there is an extremely small chance of collision, use DAD.

Where this is not a concern, set DupAddrDetectTransmits to zero.

I don't see a contradiction :-)

Section 6, first paragraph:

This is the first mention of ICMP I find in the document. It would be
helpful to mention that the messages defined in this document are ICMP
extensions early in the draft. (Same comment for Mobility Header
messages in section 6.3)

I will consider it.

6.1.2, 3rd paragraph from the end of page 23:

"If a New CoA option is present following the New
   Router Prefix Information option, the MN SHOULD use the supplied
NCoA
   and send FBU immediately or else stand to lose service."

Why is this not a MUST? Loosing service is a drastic result for
ignoring a SHOULD.

Good point. Okay with MUST. 

6.5, paragraphs 1-2:

You state that all options are of the form described in Figure 10, but
that's not necessarily true for Mobility Header LLA. I suggest
treating ICMPv6 and Mobility Header options separately.

Ah, good catch. BADF does not have Option-Code.

9, paragraph 2:

What security properties are required of the security mechanism?

These are described in detail in draft-ietf-mipshop-handover-key-03.txt

section 9, 2nd to last paragraph:

"IPsec ESP [rfc4303] in transport mode with
   mandatory integrity protection SHOULD be used for protecting the
   signaling messages.  "

Why is this a SHOULD and not a MUST?

I guess you could use ESP in tunnel mode too. We are recommending using
transport mode integrity protection.

Appendix B:

Do you expect the change log to be published in the final RFC? A list

of changes from RFC4068, rather than a list of changes for each draft

revision, would be more helpful for implementors.

This is in the tracker www.mip4.org/issues/tracker/mipshop

Thanks again,

-Rajeev

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art