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

[Vijay Devarapalli <[e-mail]>]

James Kempf wrote:

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

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.

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

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?

I will follow up on the other thread.

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

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

Vijay

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