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

[Rajeev Koodli <[e-mail]>]

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
> 
> 

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




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