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

[Vijay Devarapalli <[e-mail]>]

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

Rajeev Koodli wrote:
> 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