Subject: Re: [nemo] Last call for draft-ietf-nemo-basic-support-01.txt

From: Chan-Wah NG <[email-masked]>
Date: Wed, 05 Nov 2003 17:26:44 +0800

Hello,

Here are some issues on the NEMO Basic Support.  Most are of cosmetic
nature requiring only minor editorial changes, but I would like to call
upon the WG's attention on the first 3 issues, which in my opinion must
be resolved before the draft can go through LC (and presumably be
submitted to the IESG).

Major (or Non-Minor) Issues
---------------------------

(1) IANA Considerations - Page 25 - Section 9

In addition to the mobility options type, I would think that the various
new Status values in Binding Acknowledgement need IANA considerations as
well when MIPv6 becomes an RFC, though I am not too sure what needs and
what does not need IANA considerations.  

(2) Is Issue 11 resolved? 

Three modes of operations were specified for NEMO operations.  It was
explicitly stated that the Home Agent MUST implement all three (which
partially resolved issue 11).  However, no such statement were made
about the Mobile Router.  I presume it means that the Mobile Router is
free to implement any combinations of the three.  According to the
Issues webpage, there seems to be a consensus on issue 11 that there
will be explicit statements specifying the mobile router implement any
one of the modes.  However, I fail to find such statement in the -01
draft.  Might be also helpful to discuss which mode is better suited for
what situations.

(3) ESP is a MUST? - Page 24, Sect 7

The last sentence of Section 7 says the "tunneled routing messages MUST
be authenticated and encrypted using IPsec ESP in tunnel mode".  Even
the original MIPv6 Specs (-24) is not so strict in specifying what kind
of encryption scheme must be used to protect the BU.  I suggest adopting
an approach similar to MIPv6 by requiring that MR and HA "MUST support
and SHOULD use IPsec ESP to protect ...".  This forces MR and HA to
implements ESP as a baseline for interoperability, yet allows
implementors to choose other forms of encryption when both MR and HA
implement it.

Minor Editorial Issues
-----------------------

(1) Page 1 - Title: "Nemo Basic Support Protocol"

I am under the assumption that it is generally considered not very good
style to use non-well-known abbreviation in I-Draft/RFC titles (well
known being limited to a very small range of abbreviations like IP, TCP,
UDP).   It might be a good idea to change the title to "Network Mobility
Basic Support Protocol".  On the same note, a lot of abbreviations are
used without giving their full meanings in the document, like OSPF,
RIPng, ESP, etc.  Though proper end reference are given, it might be
good to expand them when they are first used, instead of forcing readers
to dig into end-references to get the fully-expanded phrase.

(2) Page 5 - Sect 2. Terminology

The appearance of definition of 'Prefix Table' is awkward.  There is no
sentence in the preceding paragraph leading to it. Some sentences like
'In addition, the following term is defined ... ' or the equivalence
might be necessary.

(3) Page 11 - Sect 4.3 Mobile Network Prefix Option

It might be better to change 'contains' to 'containing' to be consistent
with the use of continuous tense in the descriptions of other fields.

(4) Page 11 - Sect 4.4 Mobile Network Prefix Length Option

2nd Paragraph: 'The Mobile Network Option cannot be present ...'
Perhaps we should use the stronger phrase of 'MUST NOT' instead, since
RFC2119 does not contain the term 'cannot'.

(5) Page 14 - Sect 5.3 Recieving Binding Acknoweldgement

The last line of the page, a space after the period '.' is missing.
--> '... Network.The ...'

(6) Page 19 - Sect 6.2

 The first bullet of the second paragraph, 3rd line, '... MUST be an
Home Address ...'.
 'an' --> 'a'?
 
(7) Page 22 - Sect 6.6

The first paragraph, '.. same rules it uses for sending Binding
Acknowledgment to Mobile Hosts, ...' : Perhaps a reference to [1] will
be nice to explicitly define what those 'same rules' are?

(8) Page 23 - Sect 7

1st paragraph, 4th line, ' ... to run a intra-domain ...'
'a' -> 'an'?

(9) Page 7 - Sect 1

2nd paragraph on Page 7, the abbreviation 'HA' is first used without
explanation.  In most part of the document, the full term 'Home Agent'
is used, with occasional use of 'HA' popping up.  I suggest searching
through the document and replace 'HA' with 'Home Agent' for coherence
and consistence.

(10) Page 25 - Sect 8

The 5th line in the 2nd paragraph: "The source address of the outer IPv6
header MUST be set the Mobile Router's ..." should read "... MUST be set
to the ...".  Continuing from this line, "... MUST belong to the Mobile
Network Prefix owned by the Mobile Router" suggest only one prefix can
be owned by a mobile router.  It should perhaps be changed to "... MUST
belong to one of the Mobile Network Prefix(es) owned ...".

(11) Page 25 - Sect 9

A period is missing in the last sentence of Sect 9.

(12) Page 17 - Sect 5.5

Last sentence in this section is a 'See [3].'  Should be changed to a
better formulated sentence, such as 'Please refer to [3] for more
details' or something like that.

(13) Page 20 - Sect 6.2

Pardon my poor command of English, but the second last paragraph of Sect
6.2 is difficult to read.  I suspect the word 'like' in "... by
multicasting onto the home like a Neighbor ..." is mis-typed (my guess
is the correct word is 'link', but I am not too sure because the way the
sentence was structured).  In addition, the 2nd sentence in the same
paragraph begins with "All fields in each such Neighbor Advertisement
..." , in my humble opinion, should read "... every such ...". 
Furthermore, this is one of the rare paragraphs in the whole document
where "mobile router" is not first-letter-captitalized.

(14) Clarifications on Sect 5.6.

It was unclear to me on the first few reads that the first paragraph
refer to the behaviour when the mobile router is at home, and the next
paragraphs refer to the behaviour when mobile router is away.  Perhaps
some annotation or opening phrases like 'When the Mobile Router is at
home, ...' and 'When the Mobile Router is away, ...' should precede
paragraph 1 and paragraph 2 respectively.

/rgds
/cwng

On Fri, 2003-10-24 at 17:27, T.J. Kniveton wrote:
> Hi folks,
> 
> The Basic Support draft has been issued for a while now and has had no
> significant issues pending in this version. We would like to encourage
> everyone in the working group to make sure you have read this draft and
> contributed any open issues so that they can be resolved and we can move on
> from this charter item.
> 
> So, we would like to issue a working group last call for this draft, which
> will extend for two weeks, until November 7th. Based on the response during
> this time, the working group will decide how to update the draft and move
> forward.
> 
> Thanks,
> 
> -TJ Kniveton, Thierry Ernst.
> NEMO chairs
> 
> 
>

---

From: Chan-Wah NG <[email-masked]>
Date: Wed, 05 Nov 2003 17:26:44 +0800

Hello,

Minor Editorial Issues
-----------------------

(6) Page 19 - Sect 6.2

(7) Page 22 - Sect 6.6

(8) Page 23 - Sect 7

(9) Page 7 - Sect 1

(10) Page 25 - Sect 8

(11) Page 25 - Sect 9

(12) Page 17 - Sect 5.5

(13) Page 20 - Sect 6.2

/rgds
/cwng

---

From: Thomas Narten <[email-masked]>
Date: Wed, 05 Nov 2003 08:53:18 -0500

> be resolved before the draft can go through LC (and presumably be

Any reason not to forward these comments to the WG directly?

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Wed, 05 Nov 2003 08:53:18 -0500

Thomas

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 05 Nov 2003 10:22:40 -0800

> Major (or Non-Minor) Issues

good question. since Mobile IPv6 specificaction does not require IANA
action for Binding Ack status values and defines them in the document
itself, we assumed we should do the same. but now that the Binding Ack
status values are spread over two differnt documents (and maybe more
in the future), maybe IANA needs to be involved. I am not sure.

I think this needs AD clarification...

> draft.  

section 5.2

    The Mobile Router uses
    one of the following modes to instruct the Home Agent to determine
    the prefixes owned by the Mobile Router.  In all three modes, the
    Mobile Router sets the Mobile Router flag 'R'.

 > Might be also helpful to discuss which mode is better suited for
> what situations.

thats a rathole... :) one mode that should work in all cases, is the
Explicit Network mode.

> of encryption scheme must be used to protect the BU.  

I think you misunderstood this. the basic support document does not
require ESP tunnel encryption for Binding Updates. section 7 is about
dynamic routing protocol messages. routing protocol messages from the
Home Agent to the Mobile Router could potentially contain a lot of
information about the internal routing structure of the home domain.
simple authentication wont be enough if these messages could be
observed by others. that is why the strict requirement.

> Basic Support Protocol".  

I am fine with the suggestion.

 > On the same note, a lot of abbreviations are

if you are implementing NEMO, you better have heard about OSPF, RIP
and ESP. :) seriously, I think they are too well known.

> paragraph 1 and paragraph 2 respectively.

thanks for catching all these.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 05 Nov 2003 10:22:40 -0800

section 5.2

    The Mobile Router uses

Vijay

---

From: Chan-Wah NG <[email-masked]>
Date: Thu, 06 Nov 2003 12:49:06 +0800

Hello Vijay,

Please see responses in-line.

/rgds
/cwng

> in the future), maybe IANA needs to be involved. I am not sure.
That's what I thought too.

>     Mobile Router sets the Mobile Router flag 'R'.

I would actually prefer a stronger indication involving one of the MUST
MIGHT SHOULD etc keywords, but that's just me.

> require ESP tunnel encryption for Binding Updates. 

I presume Binding Updates are protected the same way as MIPv6 specified,
which is that BU MUST be protected using an IPsec security association,
and both MN and HA MUST support and SHOULD use ESP.  So there is no
misunderstanding there.

> section 7 is about

Yes, I understand that as well.  I am not questioning the need to
encrypt tunnel packets containing routing protocols messages.  I am just
asking do we need to limit the encryption mechanism to ESP? I understand
ESP is the currently prevailing (perhaps even the only) mechanism that
encrypt a payload packet in tunneled mode, but there might be new
protocols in the future.  By saying "tunneled routing messages MUST be
authenticated and encrypted by using IPsec ESP in tunnel mode", you are
closing the door to using other mechanisms.  I would prefer the MIPv6
style of saying saying the tunnel messages must be encrypted,and using
ESP as the encryption mechanism MUST be supported and SHOULD be used by
MR and HA".

> and ESP. :) seriously, I think they are too well known.

I am not so sure, but to quote the "Guidelines to Authors of
Internet-Drafts" on the IETF webpage, I will rather 'err on the side of
explicitness'.

> thanks for catching all these.

Don't mention it, it is afterall a WG document, and it is our job to
make sure the document is presentation-wise as well as technical-wise
sound before submitting it to the IESG.

/rgds
/cwng

---

From: Chan-Wah NG <[email-masked]>
Date: Thu, 06 Nov 2003 12:49:06 +0800

Hello Vijay,

/rgds
/cwng

/rgds
/cwng

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 06 Nov 2003 14:06:31 -0800

> MIGHT SHOULD etc keywords, but that's just me.

MUST/SHOULD are sometimes indiscriminately. they should be used
mainly to make sure the protocol is interoperable.

for example saying "the Mobile Router should do..." is stronger
than saying "the Mobile Router SHOULD do...".

in this particular case, we are just describing the basic protocol
operation. there is no question of the Mobile Router not using any
of the three modes specified in the draft. there is no need for
these keywords.

> ESP as the encryption mechanism MUST be supported and SHOULD be used by

good point. I am fine with SHOULD.

others?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 06 Nov 2003 14:06:31 -0800

others?

Vijay

---

From: "S. Felix Wu" <[email-masked]>
Date: Tue, 11 Nov 2003 19:10:44 -0800

Hi, Vijay and others,

I appologize for being late in offering comments (finally, got
some time to read through the draft). I have one question here,
which I hope that you can clarify:

- ICMP error message processing within the IP-in-IP tunnel:

In rfc2473,

 > 8. IPv6 Tunnel Error Processing and Reporting
 >
 >   IPv6 Tunneling follows the general rule that an error detected
 >   during the processing of an IPv6 packet is reported through an
 >   ICMP message to the source of the packet.
....
 >   An error detected by a node inside a tunnel is reported to the
 >   source of the tunnel packet, that is, the tunnel entry-point node.
 >   The ICMP message sent to the tunnel entry-point node has as ICMP
 >   payload the tunnel IPv6 packet that has the original packet as
 >   its payload.
 >
 >   The cause of a packet error encountered inside a tunnel can be a
 >   problem with:
 >
 >        (a)  the tunnel header, or
 >        (b)  the tunnel packet.
 >
 >   Both tunnel header and tunnel packet problems are reported to the
 >   tunnel entry-point node.
 >
 >   If a tunnel packet problem is a consequence of a problem with the
 >   original packet, which is the payload of the tunnel packet, then
 >   the problem is also reported to the source of the original packet.
 >
 >   To report a problem detected inside the tunnel to the source of an
 >   original packet, the tunnel entry point node must relay the ICMP
 >   message received from inside the tunnel to the source of that
 >   original IPv6 packet.

First, under NEMO, the MR, as the tunnel end point, might receive the
ICMP error message for a IP-in-IP tunneled packet in its tunnel.
According to rfc2473, there are a few cases that the MR indeed needs
to relay this ICMP message to the MNN (the original source). (My
clarification question here is "I assume that nemo inherently and
strictly will follow rfc2473 in MR processing of ICMP messages, isn't
it?)

Second, according to rfc2463 (ICMP for IPv6), the ICMP message should
include as much as possible the original packet. Since the ICMP packet
is produced within the tunnel, this would mean that the tunnel header
as well as the original packet header will both be sent to the MNN (if
I read both rfc2473 and rfc2463 correctly).

If this is true, then the MNN will have a way (by intentionally
injecting a packet toward some CN and causing ICMP errors within the
tunnel according rfc2473) to obtain information regarding both the
care-of and the current HA addresses (two tunnel end-points).

In MIPv6, this is NOT be an issue because MN knows this information
already. But, in NEMO, should MNN be exposed (or allowed to expose) to
such information? Some of the attacks we are constructing actually need
this piece of information.

Any comments will be highly appreciated.
-Felix

-- 
----------------------------------------------------------------------
Dr. S. (Shyhtsun) Felix Wu                           [email-masked]
Associate Professor                      http://www.cs.ucdavis.edu/~wu
Computer Science Department                     office: 1-530-754-7070
University of California at Davis               fax:    1-530-752-4767
----------------------------------------------------------------------

---

From: "S. Felix Wu" <[email-masked]>
Date: Tue, 11 Nov 2003 19:10:44 -0800

Hi, Vijay and others,

In rfc2473,

....

---

From: Chan-Wah NG <[email-masked]>
Date: Thu, 13 Nov 2003 00:41:04 +0800

Hello Felix,

Interesting, in fact if I read the problem correctly, it is also a
'problem' (sort-of) in MIPv6 as well.  Consider CN in non-optimized mode
sending a ill-formed packet that will cause an ICMP error be generated
within the HA-MN tunnel, and thus learn information about home-network
of the mobile node. (Since according to the text you quoted, the HA must
relay the ICMP error to the sender -- CN -- as well)

However, having said that, in both cases (i.e. (i) CN is the sender and
(ii) LMN/MN is the sender), it is questionable on how this can be
achieved, since the 'ill-formed' packet must be constructed such that
(a) from the sender to the tunnel entry point, an error will not be
detected by forwarding nodes and thus no ICMP error messages will not be
generated, and (b) a forwarding node within the path of the tunnel will
actually trigger an error due to the inner packet.

Like to hear others' view on this.

/rgds
/cwng

---

From: Chan-Wah NG <[email-masked]>
Date: Thu, 13 Nov 2003 00:41:04 +0800

Hello Felix,

/rgds
/cwng

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Nov 2003 09:54:38 -0800

good, this is the kind of detailed threat analysis I like to see.

> strictly will follow rfc2473 in MR processing of ICMP messages, isn't

yes, of course. unless we see a problem.

> I read both rfc2473 and rfc2463 correctly).

I am missing something here....

if there is a problem with the outer header, the response goes back
to the MR. the MNN will not get the ICMP error.

if there is a problem with the inner header, it means the Home Agent
has already stripped the outer header and some node (could be the
Home Agent also) is trying processing the inner packet. in this case,
the nodes send the ICMP error back to the MNN. the Home Agent, when it
tries to send the ICMP error back to the MNN, tunnels the error to the
MR. the MR removes the outer tunnel headers and forwards the ICMP error
alone to the MNN. the MNN will not get information about the tunnel
between the MR and the HA.

let me know what I am missing.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Nov 2003 09:54:38 -0800

Vijay

---

From: "S. Felix Wu" <[email-masked]>
Date: Wed, 12 Nov 2003 09:59:41 -0800

Hi, Chan-Wah and others,

Thanks for the comments.

I re-readed rfc2473 and found the following text:

    Fig.7 path #2 and Fig.8 (b) - The IPv6 tunnel error input
    decapsulates the tunnel IPv6 packet, which is the ICMPv6 message
    payload, obtaining the original packet, and thus the original headers
    and dispatches the "internal error code", the source address from the
    original packet header, and the original packet, down to the error
    report block of the protocol identified by the Next Header field in
    the tunnel header immediately preceding the original packet in the
    ICMP message payload.

It looks to me at this point, according to the rfc, only the "original
packet" part of the ICMP message should be relayed to the original
source (which is MNN or CN, as you mentioned). So, we should not have
any concerns in MIPv6 or NEMO if the implementation of rfc2473 is
correct.

Thanks.
-Felix

---

From: "S. Felix Wu" <[email-masked]>
Date: Wed, 12 Nov 2003 09:59:41 -0800

Hi, Chan-Wah and others,

Thanks for the comments.

Thanks.
-Felix

---

From: "S. Felix Wu" <[email-masked]>
Date: Wed, 12 Nov 2003 13:58:21 -0800

Dear Vijay,

> good, this is the kind of detailed threat analysis I like to see.
Thanks. Yes, I agree that we should look for something more specific
to the nemo itself.

> between the MR and the HA.

according to the RFC, in some situations, the ICMP message should
also be forwarded to the MNN. But, later (after I sent out my first
email -- appologize for that), I also found that even under these
cases (i.e., the MR needs to send/forward ICMP messages to MNN, the
source of the original packet), the tunnel header information will
be removed according to the same rfc.

Thanks.
-Felix