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

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

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