Subject: [MEXT] FW: RE: draft-ietf-mext-nemo-pd-04 review

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 5 Apr 2010 17:14:36 -0700

FYI - below is a review of draft-ietf-mext-nemo-pd-04 from Michaela Vanderveen. Thanks Michaela for taking the time to review the draft!

--julien

_____________________________________________
From: Vanderveen, Michaela
Sent: Thursday, April 01, 2010 6:42 PM
To: Laganier, Julien
Subject: RE: draft-ietf-mext-nemo-pd review

I have read the document, and it is fairly well explained. Some comments below, mixed from not too major to very minor typos. I'm a bit nit-picky so you might feel regret that you asked :). But overall it would not be too bad for a WGLC.

Section 3: "DHCPv6PD can be used to meet this requirement for
   prefix delegation.". Are there any other ways to meet the prefix delegation requirement? If so it should be mentioned.

---------------------

Section 3.1: "with a DHCPv6 Solicit message
   as described in section 17 of RFC 3315<http://tools.ietf.org/html/rfc3315> and section 12.1 of RFC 3633<http://tools.ietf.org/html/rfc3633>.
   Once the MR has been delegated a set of prefixes from the HA, "
The request message is described fairly detailed (name of message, two references), while the response message is absent (the fact that there is a response message is INFERRED from the sentence after it. So, in brief, HOW is the MR delegated a set of prefixes?

Last sentence in first paragraph of section 3.1. should be broken in two, since it goes on for nine lines.

Also, I would change the title from
"When the MR uses DHCPv6" to "MR use of DHCPv6"

There is a Figure for the case when the MR has prefixes, but none for when it doesn't. Why not? Can one figure have an optional first transaction to show what happens when the MR does not have any prefixes? This way both cases are captured.

Section 3.2:
In the paragraph "The DHCPv6 messages exchanged between the HA and the MR originate
   only with the HA and the MR, and therefore are not "intercepted
   packets" (i.e. the sender of the packets is a third node on the home
   link)
the statement in parenthesis is confusing. Should it be "the sender of the packets is NOT a third node"? If that's what "intercepted" means?

Also, "originate only with the HA" -> "originate only at the HA".
Section 3.3 starts off declaring that DHCPv6 relay is an "alternative"  which I guess it's an alternative to the configuration of the last sentence of section 3.2. Perhaps that sentence in section 3.2 can be followed by something like "Alternatively, the method in section 3.3 may be used"

Typo: missing parens ): See Figure 3

Section 3.3.1: A bit strange reasoning: the relay agent assumes that the HA hosts the next hop [...] therefore, the MR MUST configure the relay agent to forward.." So, the reason behind this strong requirement is just an assumption on the side of the relay agent- why is that? Some mandated compliance of the agent with some RFC? Common deployments of relay agents? Not clear.
---------------
Section 3.3.3: typo (extra comma) : The way in which, the -> The way in which the

Section 3.5: The MR can determine if an HA provides DHCPv6PD by
   initiating a DHCPv6 message exchange in which the MR requests
   delegated prefix(es).
It is not clear what that message is, is it DHCPv6 Solicit?

"the MR has also to setup a tunnel" -> "the MR has to also setup a tunnel" Might also help to specify WHEN it's supposed to set up a tunnel- before or after the query? Obviously before, but that is misleading from the  wording above, where the "also" implies almost an afterthought. I would rephrase as :"the MR has to have already set up a tunnel with.."

Strangely strong requirement: MR MUST discontinue sending Solicit messages to
   the HA after sending 6 Solicit
because 6 is a number pulled out of a hat - e.g it's an implementation issue really (if I want to send only 5, or I want to send 7, would that BREAK the protocol? Or cause undue harm?) so I would really change that MUST to SHOULD.

Section 3.6: is too short in my opinion. I think it deserves a bit more explanation.

Section 3.7: second paragraph is unclear;

It first cites that a protocol may be required, then it goes on to say that a relay agent function is not required. So, there was a jump in the interpretation of the cited text to mean that the "protocol" is a "relay agent", which does not follow.

Also, last sentence, "NEMO explicit mode is recommended to take advantage of the function
   already defined for NEMO.
could be made a little more precise as to what the "function" is.

Section 3.8: typo "MH" -> MN. (I don't think MN's are defined in this doc, though of course everyone knows what it is)

Security considerations:

"Because the relay agents and servers must be manually configured" I find it hard to believe the "must". Might be better to say "are typically manually configured".

In general, it seems to me that the security considerations section focuses on the HA-DCHPserver link, not on the MR-HA link, which is tunneled anyway. That's where they mention IPSec, which I guess it's fine for server to server. These server to server issues often end up being manually configured and there is not much that a standards body can do to mandate anything. Is your concern about the MR to HA link? I'm not sure I understand your concern.

Cheers,

Michaela

_____________________________________________
From: Laganier, Julien
Sent: Thursday, April 01, 2010 7:19 AM
To: Vanderveen, Michaela
Cc: Tony Cheneau
Subject: RE: IETF draft review

Hi Michaela,

Thanks for the offer =)

I'd like to get a review of http://tools.ietf.org/html/draft-ietf-mext-nemo-pd-04

It's not rocket science, it simply documents the use of DHCP prefix delegation in the context of network mobility. Please have a look at the whole document to help improve readability. In addition, I believe the security considerations of the draft to be inappropriate. It makes various claims about security provided by the mobile network infrastructure, then goes on recommending DHCP security mechanisms to be used, before finally outlining how IPsec could be used. In MIPv6 there is always IPsec SAs between the MN and the HA and I believe those MUST be used to protect the DHCP PD signaling. The draft also does not state what the IPsec SPD and SAD entries would be, as in RFC 4877.

Thank you.

--julien

_____________________________________________
From: Vanderveen, Michaela
Sent: Thursday, April 01, 2010 6:29 AM
To: Laganier, Julien
Cc: Tony Cheneau
Subject: IETF draft review

Hi Julien,

As Tony Cheneau already informed you, we are in need of reviews for our draft in CSI, regarding ECC support in CGA/SEND.  I am willing to review a draft that you are seeking reviewers for, in exchange for this service :).  Is there a draft you would like me to review? My expertise in general security- all layers--, and I was involved in a couple of WGs (hokey,csi), attending IETF meetings once a year, but now am not as active as in the past.
Thanks

Michaela

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 11 Apr 2010 19:24:30 +0200

Hi Julien,

Thanks Julien and Michaela for the review. Please see some comments
inline below.

On Mon, 2010-04-05 at 17:14 -0700, Laganier, Julien wrote: 
> FYI – below is a review of draft-ietf-mext-nemo-pd-04 from Michaela
> Vanderveen. Thanks Michaela for taking the time to review the draft!
>  
> --julien
>  
> I have read the document, and it is fairly well explained. Some
> comments below, mixed from not too major to very minor typos. I’m a
> bit nit-picky so you might feel regret that you asked J. But overall
> it would not be too bad for a WGLC.
>  
> Section 3: “DHCPv6PD can be used to meet this requirement for
>    prefix delegation.”. Are there any other ways to meet the prefix
> delegation requirement? If so it should be mentioned.

As far as I know, there are no other ways standardized, though sure
there might be others. Therefore I understand that it is not needed to
mention, since we would be referring to a (potentially incomplete) set
of non-standard mechanisms.

>  
> ---------------------
>  
> Section 3.1: “with a DHCPv6 Solicit message
>    as described in section 17 of RFC 3315 and section 12.1 of RFC
> 3633.
>    Once the MR has been delegated a set of prefixes from the HA, “
> The request message is described fairly detailed (name of message, two
> references), while the response message is absent (the fact that there
> is a response message is INFERRED from the sentence after it. So, in
> brief, HOW is the MR delegated a set of prefixes?

I've added a couple of sentences describing the whole sentence (Solicit,
Advertise, Request, Reply).

> two, since it goes on for nine lines.

OK, done.

> “When the MR uses DHCPv6” to “MR use of DHCPv6”

OK.

>  
> There is a Figure for the case when the MR has prefixes, but none for
> when it doesn’t. Why not? Can one figure have an optional first
> transaction to show what happens when the MR does not have any
> prefixes? This way both cases are captured.

What figure are you referring to? In all the figures, the MR is assumed
not to have any prefix and uses DHCPv6PD to obtain them. I think I'm
missing something here?

>  
> Section 3.2:
> In the paragraph “The DHCPv6 messages exchanged between the HA and the
> MR originate
> the statement in parenthesis is confusing. Should it be “the sender of
> the packets is NOT a third node”? If that’s what “intercepted” means?

As a result of Jean-Michel's comment, the paragraph was rewritten and
this does not apply anymore. Besides, this part is still under
discussion.

>  
> Also, “originate only with the HA” -> “originate only at the HA”.
> Section 3.3 starts off declaring that DHCPv6 relay is an “alternative”
> which I guess it’s an alternative to the configuration of the last
> sentence of section 3.2. Perhaps that sentence in section 3.2 can be
> followed by something like “Alternatively, the method in section 3.3
> may be used”

OK.

> Typo: missing parens ): See Figure 3

Fixed, thanks.

>  
> Section 3.3.1: A bit strange reasoning: the relay agent assumes that
> the HA hosts the next hop […] therefore, the MR MUST configure the
> relay agent to forward..” So, the reason behind this strong
> requirement is just an assumption on the side of the relay agent- why
> is that? Some mandated compliance of the agent with some RFC? Common
> deployments of relay agents? Not clear.

This is basically a deployment consideration of DHCPv6PD for NEMO. For
simplification purposes we assume that the relay/server is on the HA, so
no discovery/additional signalling is required. Do you think we need to
explicitly state that on the draft?

Fixed, thanks.

> It is not clear what that message is, is it DHCPv6 Solicit?

Yes, I've made this explicit in the text.

>  
> “the MR has also to setup a tunnel” -> “the MR has to also setup a
> tunnel” Might also help to specify WHEN it’s supposed to set up a

Fixed, thanks.

>  tunnel- before or after the query? Obviously before, but that is
> misleading from the  wording above, where the “also” implies almost an
> afterthought. I would rephrase as :”the MR has to have already set up
> a tunnel with..”

OK, changed.

> because 6 is a number pulled out of a hat – e.g it’s an implementation
> issue really (if I want to send only 5, or I want to send 7, would
> that BREAK the protocol? Or cause undue harm?) so I would really
> change that MUST to SHOULD.

OK.

> Section 3.6: is too short in my opinion. I think it deserves a bit

This is related to pure DHCPv6. IMHO, it's better not to duplicate text
from DHCPv6 in this draft, unless it's really specific to the NEMO-PD
use case.

> It first cites that a protocol may be required, then it goes on to say
> that a relay agent function is not required. So, there was a jump in
> the interpretation of the cited text to mean that the “protocol” is a
> “relay agent”, which does not follow.

I've updated a bit the text, so now it reads as follows:

        "The use of a DHCPv6 relay agent at the HA in DHCPv6PD may
        require "a protocol or other out-of-band communication to
        add routing information for delegated prefixes into the
        provider edge router" (section 14 of RFC 3633). If the
        DHCPv6PD DR function is implemented in the HA for the MR,
        no relay agent function is required, since the HA is the
        anchor point for the MR's prefixes."

>  
> Also, last sentence, “NEMO explicit mode is recommended to take
> advantage of the function
> could be made a little more precise as to what the “function” is. 

OK, suggested text:

        "NEMO explicit mode is recommended to take advantage of
        the function (i.e. the prefixes are included in the BU,
        carried in MNP options) already defined in NEMO for the HA
        to know about the delegated prefixes of the MR."

>  
>  
>  
> Section 3.8: typo “MH” -> MN. (I don’t think MN’s are defined in this
> doc, though of course everyone knows what it is)

Fixed, thanks.

>  
> Security considerations:
>  
> “Because the relay agents and servers must be manually configured” I
> find it hard to believe the “must”. Might be better to say “are
> typically manually configured”.

Well, this is text from RFC3315, so I prefer not to change it.

>  
> In general, it seems to me that the security considerations section
> focuses on the HA-DCHPserver link, not on the MR-HA link, which is
> tunneled anyway. That’s where they mention IPSec, which I guess it’s
> fine for server to server. These server to server issues often end up
> being manually configured and there is not much that a standards body
> can do to mandate anything. Is your concern about the MR to HA link?
> I’m not sure I understand your concern.

Yep, this is one of the main concerns. We may also need to add something
for the next revision about ensuring that the prefixes used by NEMO are
actually  the ones obtained from NEMO-PD.
 
> Cheers,

Thanks a lot.

Carlos

> I’d like to get a review of
> http://tools.ietf.org/html/draft-ietf-mext-nemo-pd-04
>  
> It’s not rocket science, it simply documents the use of DHCP prefix
> delegation in the context of network mobility. Please have a look at
> the whole document to help improve readability. In addition, I believe
> the security considerations of the draft to be inappropriate. It makes
> various claims about security provided by the mobile network
> infrastructure, then goes on recommending DHCP security mechanisms to
> be used, before finally outlining how IPsec could be used. In MIPv6
> there is always IPsec SAs between the MN and the HA and I believe
> those MUST be used to protect the DHCP PD signaling. The draft also
> does not state what the IPsec SPD and SAD entries would be, as in RFC
> 4877.
>  
> Thank you.
>  
> --julien
>  
> As Tony Cheneau already informed you, we are in need of reviews for
> our draft in CSI, regarding ECC support in CGA/SEND.  I am willing to
> review a draft that you are seeking reviewers for, in exchange for
> this service J.  Is there a draft you would like me to review? My
> expertise in general security- all layers--, and I was involved in a
> couple of WGs (hokey,csi), attending IETF meetings once a year, but
> now am not as active as in the past. 
> Thanks
>  
>  
> Michaela
>  
>  
>  

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67