Subject: [Mipshop] Comments on draft-ietf-mipshop-handover-key-01.txt

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Sep 2007 11:38:42 -0700

Hello,

I have a few minor comments on this draft.

There is some confusion in the document about two different options, 
"Handover Key Encryption public key option" and "Handover Key Request 
Option". Both are used in the text. But in section 4, there is only the 
Handover Key Request Option defined.

In section 4.1, you should have a field that tells what the length of 
the key is rather than what how much padding has been added. Since the 
"Length" field is a multiple of 8 octets, you know how much padding has 
been added based on the length of other fields. If the key length is 
fixed, then again you know much padding has been added. So in both 
cases, you don't need the "Pad Length" field.

In section 4.2, the field "Key Hash" is not shown as a 128-bit field in 
the figure. Suggested change

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  Pad Length   |  AT   |Resrvd.|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                           Key Hash                            +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   .                                                               .
   .                    Encrypted Handover Key                     .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                           Padding                             .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Again, I don't think you need the "Pad Length" field.

In section 1, replace

>  The message exchange between the MN and AR 
>  to provision the key is required to be protected by SEND;

with

    The message exchange between the MN and AR
    to provision the handover key is required to be protected by SEND;

I am confused by the following text

>      If the AR does not respond to the PrRtSol, as would be the case if 
>      the proxy router functionality is not deployed, the MN MAY include 
>      the Handover Key Request option in a standard IPv6 SEND-protected 
>      Router Solicitation (RS) instead [RFC2461].  

If the AR does not respond to PrRtSol, is it compliant to 4068bis? I saw 
the exchange with Julien. I agree that exchanging the neighborhood 
information is optional, but responding to a Proxy Router Solicitation 
for a mobile node is not option. The access router must respond with 
whatever information it has, right?

In section 3.7

>      HKEPK-HANDOVERS:  The maximum number of handovers for which the 
>                         handover key encryption public key should be 
>                         reused. Default is 10. 

Just curious, why 10?

Vijay

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Sep 2007 13:24:27 -0700

Hi Vijay,

Responses  below (jak>>).

jak>> Ah, right, I forgot to change the text everywhere.

jak>> This is how it was done with SEND. The advantage of this is
that the field can be only 8 bits instead of 16 and thereby allow an
arbitrary sized key.

    0                   1                   2                   3

jak>> Per the discussion with Julian, the Key Hash is unnecessary if the
SEND nonce is included, which it must be for anti-replay protection. So
I've dropped the Key Hash.

In section 1, replace

with

jak>> OK.

jak>> Right, I believe that PrRtSol/PrRtAdv is optional to deploy. If it not 
deployed, there will be no PrRtAdv response if the MN deploys it and sends 
the PrRtSol but the AR does not. If neither do, then the MN would just use 
the RS/RA from the start.

jak>> Dunno about this. The FMIP spec says nothing about how this 
optionality should be handled. There is no recommendation of a configuration 
variable or anything on the MN to indicate whether it is deployed, nor any 
indication from the router if it deploys the PrRt methods which would let 
the MN decide which to send. So there is not much we can do in this spec 
with respect to providing guidance about how to do the key exchange if the 
PrRtSol/PrRtAdv is not deployed, except to say that if the MN doesn't get a 
response, it should try something different.

jak>> Any suggestions about how to fix this?

In section 3.7

Just curious, why 10?

jak>> I did not do an extensive analysis on probability of cracking the RSA 
key to come up with the number. Is there another number you think would be 
more appropriate?

                       jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 18 Sep 2007 13:48:30 -0700

RtSolPr/PrRtAdv are MUST for MNs and ARs that support FMIP. If that
functionality is provided by an access network by some other means, they may
not be used. In such a case, a MN sends RtSolPr RTSOL_RETRIES times, and the
PAR does not reply with PrRtAdv. This is described in Handover Capability
Exchange Section. 

Perhaps we should assume that having the RtSolPr/PrRtAdv is a typical use
case.

-Rajeev

-- 
http://people.nokia.net/~rajeev

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Sep 2007 14:25:28 -0700

It is the typical use case. The problem is what to do if it isn't deployed.

            jak

----- Original Message ----- 
From: "Rajeev Koodli" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Vijay Devarapalli" 
<[email-masked]>; <[email-masked]>; "Koodli Rajeev (NSN - 
US/Palo Alto)" <[email-masked]>
Sent: Tuesday, September 18, 2007 1:48 PM
Subject: Re: Comments on draft-ietf-mipshop-handover-key-01.txt

-Rajeev

--

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Sep 2007 14:41:48 -0700

> that the field can be only 8 bits instead of 16 and thereby allow an

I don't follow. I don't know why it was done that way in RFC 3971, but 
to me it appears like a cleaner option to have a length field that tells 
what the length of the key and the rest would be padding. Anyway, both 
with work.

> I've dropped the Key Hash.

Ok.

> jak>> Right, I believe that PrRtSol/PrRtAdv is optional to deploy. If it 
> not deployed, there will be no PrRtAdv response if the MN deploys it and 
> sends the PrRtSol but the AR does not. If neither do, then the MN would 
> just use the RS/RA from the start.
> 
> optionality should be handled. There is no recommendation of a 
> configuration variable or anything on the MN to indicate whether it is 
> deployed, nor any indication from the router if it deploys the PrRt 
> methods which would let the MN decide which to send. So there is not 
> much we can do in this spec with respect to providing guidance about how 
> to do the key exchange if the PrRtSol/PrRtAdv is not deployed, except to 
> say that if the MN doesn't get a response, it should try something 
> different.
> 

I will follow up on the other thread.

> jak>> I did not do an extensive analysis on probability of cracking the 
> RSA key to come up with the number. Is there another number you think 
> would be more appropriate?

No. I just wanted to figure out if there was a reason behind "10".

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Sep 2007 14:45:27 -0700

Rajeev,

Section 5.1 in 4068bis says something different.

>     The MN expects a PrRtAdv in response to its RtSolPr message.
>     If the MN does not receive a PrRtAdv message even after
>     RTSOLPR|RETRIES, it must assume that PAR does not support the fast
>     handover protocol and stop sending any more RtSolPr messages.

This paragraph seems to say that the MN concludes that the PAR does not 
support FMIPv6

Vijay

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 18 Sep 2007 15:03:50 -0700

> This paragraph seems to say that the MN concludes that the PAR does not

Right. We could re-word it slightly differently. Or, we could just say that
the specific access network indicates that MN should not engage in RtSolPr.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Sep 2007 15:37:36 -0700

In that case, there's no need for the RS/RA protocol in 
draft-ietf-mipshop-handover-key. I had thought FMIPv6 could be supported 
w.o. PrRtSol.

I think we should keep the text like it is. Otherwise, we need some way for 
the PAR to indicate whether or not it supports FMIPv6 using standard ND 
signaling (RS/RA). I think leaving it the way it is makes things simpler.

I'll take the text out of the SEND keys draft.

       jak

----- Original Message ----- 
From: "Rajeev Koodli" <[email-masked]>
To: "ext Vijay Devarapalli" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; <[email-masked]>; "Koodli 
Rajeev (NSN - US/Palo Alto)" <[email-masked]>
Sent: Tuesday, September 18, 2007 3:03 PM
Subject: Re: Comments on draft-ietf-mipshop-handover-key-01.txt

-Rajeev

>>> not
>>> configuration
>>> RSA

--