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

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

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" <[e-mail]>
To: "ext Vijay Devarapalli" <[e-mail]>
Cc: "James Kempf" <[e-mail]>; <[e-mail]>; "Koodli 
Rajeev (NSN - US/Palo Alto)" <[e-mail]>
Sent: Tuesday, September 18, 2007 3:03 PM
Subject: Re: Comments on draft-ietf-mipshop-handover-key-01.txt






On 9/18/07 2:45 PM, "ext Vijay Devarapalli"
<[e-mail]> wrote:

> 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

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




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