Subject: [Mip6] Another review of draft-ietf-mip6-bootstrap-ps-03.txt

From: "T.J. Kniveton" <[email-masked]>
Date: Mon, 7 Nov 2005 17:41:32 -0800

Hi,

I would like to add some additional comments to those given by Jari a  
couple of months ago. Sorry that it took me a while to send all of  
these to you. I understand the document has gone through last call,  
but I feel there are issues that need to be addressed.

Obviously, a lot of work went into producing this document. Due to  
the complexity of the interlocking issues, it's quite a challenge to  
clearly and simply convey the required information. I found the  
document's wording difficult to parse in some places. Some of the  
sentences have a large number of subordinate clauses and passive  
tense that is cumbersome to untangle. I have made a number of  
suggested changes in this document. Due to the large number of  
changes, I will not list them here, but you can diff it from/merge it  
with version -03 of your document.

http://www.kniveton.com/tj/specs/draft-ietf-mip6-bootstrap-ps-03-tj.txt

In addition to the changes proposed in that version above, I also  
have the following comments for your consideration:

- Section 1.2, 2nd paragraph. Please change the phrase "is instructed  
by the Home Agent (via some form of signalling) to do so etc." --  
this is vague and doesn't make sense. The MN is instructed by the HA  
to do what?

- Section 1.2, 3rd paragraph. This paragraph seems extraneous and can  
be removed.

- Is bootstrapping applicable to mobile routers, in your opinion? If  
so, please change all occurrences of "mobile host" to "mobile node".  
If not, then please explicitly state this and make sure to use mobile  
host.

- under the term definition for "Credentials" - credentials are data,  
not a mechanism. Please remove "or mechanism", or change it to  
something that better reflects those alternative methods to obtain  
credentials.

- Under design goals, you say "The bootstrapping procedure can be  
triggered at any time . ." -- well, I would disagree with this goal  
as stated, because it makes it too easy for a DoS attack by an  
external entity continuously triggering the bootstrapping. You need  
to say something about how security is handled for this.

- Under section 5.1.1, "Prefix changes in the home network", I'm not  
sure that this is a problem, as the home agent should create that new  
security association ahead of renumbering, and the MN could derive it  
from the existing SA. Perhaps some text is needed, but basically you  
are saying that you must bootstrap to successfully renumber, which  
I'm not convinced is correct.

- 5.1.2, "Local home agents" - can you define what a local roaming  
partner is? Also in section 5.2.2, the concept of local discovery is  
not totally clear to me.

- "Ease of deployment" - it seems that you are suggesting that this  
bootstrapping could be used for infrastructureless (here you call it  
"opportunistic") scenarios. However, this is clearly stated as a non- 
goal in the Goals section and in section 2. This is also reflected in  
Section 7.4
   - Please normalize "infrastructureless" and "infrastructure-less".

- Section 5.3.1 - I don't see why this is a problem. When we designed  
renumbering, we discussed this factor, and it was concluded that the  
HA and home routers will have to serve the deprecated prefix for a  
while anyhow; perhaps, a matter of weeks or months, while the  
transition happens. Bootstrapping may aid this process, but I don't  
see how this motivates it.

- Page 15, last paragraph - this paragraph seems redundant and I  
suggest removing it. If there are terms defined here (such as serving  
MSP), they should have been described in an earlier section since  
they were already used.

- Page 16, "The service model defined here . . " -- I suggest adding  
a reference to the split scenario draft here.

   Also, the bullet points after this paragraph state that a solution  
should account for all possible permutations of home or serving MSPs  
and ASPs belonging to different administrative domains. I don't think  
this should really be a requirement -- likely deployment scenarios  
should be addressed, but the solution is overly complicated by  
supporting *all* possible configurations.

- Section 7.2 - "In this scenario the ASP and MSP are the same ASP."  
This sentence doesn't make sense to me.

- Section 7.4 - You don't describe what an IETF meeting is. Anyone  
reading this who doesn't participate in IETF meetings won't  
necessarily have enough background to follow this scenario.
   - But more importantly, as mentioned above, infrastructureless  
networks are not supported -- so why is this section here? At least  
change the title of the section to "Non-goal: Infrastructureless  
networks" or something like that.

- Page 20, 1st draft. This description of IKE is quite difficult to  
follow; please consider making it clearer.

- Parameter set 1: You have a (*) after IKE credentials, but no  
footnote to indicate what that means as you do in set 2.

- Section 9.2 - what do "or otherwise disrupt the mobile host's  
mobility service" and "or otherwise disrupt the home agent's mobility  
service" mean? In a threats section, you should be more precise.

- I recommend replacing the word "steal" with another one in all  
cases. I have replaced it with "eavesdrop on" in one place, but there  
are other occurrences.

Thanks,
TJ

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 8 Nov 2005 11:11:00 +0900

On Mon, 7 Nov 2005 17:41:32 -0800

> If not, then please explicitly state this and make sure to use mobile 

This is a question I would like to ask on this list, and also to several
other WGs (mipshop, etc): from now on, shouldn't we mandate all
specifications to consider both mobile hosts and mobile routers (when
appropriate, i.e. when not considering the specificities of a mobile
host [doesn't forward datagrams] or a mobile router [does forwarding]) ?

This might be a question for which A-Ds may be in a better position to
issue some guidance, so may be I should ask it somewhere else, but let
me have a try on this ML. 

Thierry.

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 07 Nov 2005 18:37:11 -0800

> me have a try on this ML. 

for HA discovery, HoA configuration and IPsec SA
setup, the bootstrapping mechanisms are common to
both MIPv6 and NEMO.

we probably need to clarify this in the bootstrapping
drafts.

Vijay

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 8 Nov 2005 12:53:39 +0900

On 2005/11/08, at 11:37, Vijay Devarapalli wrote:

>>> - Is bootstrapping applicable to mobile routers, in your opinion?  
>>> If  so, please change all occurrences of "mobile host" to "mobile  
>>> node".  If not, then please explicitly state this and make sure  
>>> to use mobile host.

In addition, prefix delegation is need to fit with the bootstrapping.
I don't think there is any serious issues for combining PD and  
bootstrapping,
but there might be minor issues such as optimization (specially for  
the case of DHCP)

ryuji