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

["James Kempf" <[e-mail]>]

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

            jak

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



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


On 9/18/07 1:24 PM, "ext James Kempf" <[e-mail]> wrote:

> Hi Vijay,
>
> Responses  below (jak>>).
>
> 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.
>
> jak>> Ah, right, I forgot to change the text everywhere.
>
> 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.
>
> 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.
>
> 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.
>
> 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
>
>>  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;
>
> jak>> OK.
>
> 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?
>
> 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
>
>>      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?
>
> 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
>
>

-- 






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