headers
Soliman, Hesham | 1 Aug 2005 08:55

RE: HMIPv6 security discussions in Paris


 > > The current security scheme in HMIPv6 handles cases A and 
 > B. However,
 > > the issues raised against the security scheme used were concerned
 > > with the ease of deployment of certificates on hosts.
 > 
 > If you use EAP/IKEv2, you don't have to rely on client-side certs.

=> I know :) it's going to be in the slides.

Hesham

 > 
 > Alper
 > 
 > 
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================
Permalink | Reply | 0 comments |
headers
Francis Dupont | 2 Aug 2005 11:34
Picon
Picon

larger options

I've just create a 4096 bit RSA key and encode the public part in DER.
The size is 550, draft-arkko-mipshop-cga-cba-01.txt puts CGA parameters
which includes a public key in a MIPv6 option with a maximal length of
255 octets, cf RFC 3775 section 6.2.1 page 47:
   Option Length

      8-bit unsigned integer, representing the length in octets of the
      mobility option, not including the Option Type and Option Length
      fields.

This problem is generic, I believe at least half of the mipshop I-D
use oversized option. How and where to fix this?

Regards

Francis.Dupont <at> enst-bretagne.fr

PS: a way to fix it: mark size 255 as oversized option: the real length is
in the two next octets.
Another way: use the first bit (length > 127) as oversized option:
length field is extended to two octets and the real length is taken from
them with the first bit masked...
PPS: don't forget to defined what is included in the length (I'd like
to get extended length not included).
PPPS: where is mipshop or mip6 WG. I am strongly in favor of a fast track
document. If I remember well I have a short slot at the end of mip6 WG
session this afternoon... mip6 W chairs?
Permalink | Reply | 0 comments |
headers
gabriel montenegro | 2 Aug 2005 14:26
Picon
Favicon

New Chair

For the benefit of those not present at today's meeting...
I announced today that MIPSHOP now has an additional chair:
Stefano Faccin <stefano.faccin <at> nokia.com>.

Thanks to the ADs for getting some additional help for the group,
and specially to Stefano for joining me as we start on the new
phase of MIPSHOP.

-gabriel
MIPSHOP co-chair
Permalink | Reply | 0 comments |
headers
Greg Daley | 2 Aug 2005 17:24
Picon
Picon

Re: [Mip6] larger options

Francis Dupont wrote:
> I've just create a 4096 bit RSA key and encode the public part in DER.
> The size is 550, draft-arkko-mipshop-cga-cba-01.txt puts CGA parameters
> which includes a public key in a MIPv6 option with a maximal length of
> 255 octets, cf RFC 3775 section 6.2.1 page 47:
>    Option Length
> 
>       8-bit unsigned integer, representing the length in octets of the
>       mobility option, not including the Option Type and Option Length
>       fields.
> 
> This problem is generic, I believe at least half of the mipshop I-D
> use oversized option. How and where to fix this?

MIP6 sounds like a good place.

How about the length in the IPv6 header describes the length of the
entire packet including extended options.  Mobility header
length value describes the length of the mobility header with
the original option sizes and format.  This aggregated length defined
in the MH may be smaller than the total packet size (even counting
preceding headers).

An identifier would have to be carried in the mobility header indicating
that following the exlicit length in the MH are "extended" mobility
options.

For example the next header=[MH|None], length =residual length of the
message.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francis Dupont | 2 Aug 2005 18:34
Picon
Picon

Re: [Mip6] larger options

 In your previous mail you wrote:

   MIP6 sounds like a good place.

=> I agree but the answer of mip6 WG chairs did cross your message (:-).

   How about the length in the IPv6 header describes the length of the
   entire packet including extended options.

=> I don't believe the size constraint of MH (2K) is a problem.

   I'm not sure if overloading the MH protocol number is too evil.

=> it is evil.

   Does this sound like a good or a bad idea?

=> IMHO we have just to extend option format (and only this).

Regards

Francis.Dupont <at> enst-bretagne.fr
Permalink | Reply | 0 comments |
headers
Jari Arkko | 2 Aug 2005 18:47
Picon
Picon

Re: [Mipshop] larger options

Francis Dupont wrote:

>PS: a way to fix it: mark size 255 as oversized option: the real length is
>in the two next octets.
>  
>
I don't like this very much, because current code would be
unable to skip it.

>Another way: use the first bit (length > 127) as oversized option:
>length field is extended to two octets and the real length is taken from
>them with the first bit masked...
>  
>
See above. And Greg Daley wrote:

> How about the length in the IPv6 header describes the length of the
> entire packet including extended options.  Mobility header
> length value describes the length of the mobility header with
> the original option sizes and format.  This aggregated length defined
> in the MH may be smaller than the total packet size (even counting
> preceding headers).
>
> An identifier would have to be carried in the mobility header indicating
> that following the exlicit length in the MH are "extended" mobility
> options.

This seems a bit complicated, but I got one idea from
this (more below).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Francis Dupont | 2 Aug 2005 19:26
Picon
Picon

Re: larger options

 In your previous mail you wrote:

   >PS: a way to fix it: mark size 255 as oversized option: the real length is
   >in the two next octets.

   I don't like this very much, because current code would be
   unable to skip it.

=> I am afraid this will be true with any solution, and RFC 3775 requires
to skip unknown options (argh!).

   Additional ideas:

   o    The truly long options are rare, there's likely just one (cga).

=> we can get more as nobody have taken care of this problem before today.

         Having a rule in the spec that needs this to concatenate the
         option in question if it appears multiple times would be possible.
         That is, you add, say, four options to carry the lengthy data:
            optionX(...)optionX(...)optionX(...)optionX(...)

=> this can be a nice way to avoid the skipping issue, and
this mechanism can be defined per option type. I buy it
if nobody has a better proposal.

   o    Negotiation. The things are likely to need this are probably
         going to exchange some other packets prior to this, so you might
         send a negotiation option and get another back to confirm that the
         peer supports an extended format. Then you could send
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles E. Perkins | 4 Aug 2005 13:28
Picon

Re: FMIPv6 - SPI in FBU for handover keys


Hello folks,

I still think this is a good idea, and I'm happy to resubmit the
document for consideration by the working group if there is
support for doing so.

Regards,
Charlie P.

Vijay Devarapalli wrote:

> Narayanan Vidya-CVN065 wrote:
>
>> All,
>> While writing the draft on handover keys, we had to ensure that the 
>> key is tied to the CoA of the MN, so that the AR is able to retrieve 
>> the correct key for the MN upon receiving an FBU. This is due to the 
>> fact that there is currently no way to carry an SPI in the FBU. It 
>> will be a lot cleaner if there was a way for the MN to include an SPI 
>> in the FBU sent to the oAR, so that the AR can use that to look up 
>> the SA. 
>
>
> maybe you could use
> http://www.watersprings.org/pub/id/draft-perkins-mobileip-spi-00.txt
>
> it was written a long time ago.
>
> Vijay
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Kempf | 4 Aug 2005 14:20

Re: FMIPv6 - SPI in FBU for handover keys

I like the idea of an SPI. It would allow us to name the SEND key with
something other than the address.

            jak

----- Original Message -----
From: "Charles E. Perkins" <charliep <at> iprg.nokia.com>
To: "Vijay Devarapalli" <vijayd <at> iprg.nokia.com>
Cc: "Narayanan Vidya-CVN065" <vidya <at> motorola.com>; "'Gerardo Giaretta'"
<Gerardo.Giaretta <at> TILAB.COM>; "'Julien Bournelle'"
<julien.bournelle <at> int-evry.fr>; <mipshop <at> ietf.org>; "'Rajeev Koodli'"
<rajeev.koodli <at> nokia.com>; "'James Kempf'" <Kempf <at> docomolabs-usa.com>;
"Venkitaraman Narayanan-CNV002" <Narayanan.Venkitaraman <at> motorola.com>
Sent: Thursday, August 04, 2005 4:28 AM
Subject: Re: [Mipshop] FMIPv6 - SPI in FBU for handover keys

>
> Hello folks,
>
> I still think this is a good idea, and I'm happy to resubmit the
> document for consideration by the working group if there is
> support for doing so.
>
> Regards,
> Charlie P.
>
>
>
> Vijay Devarapalli wrote:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Narayanan Vidya-CVN065 | 4 Aug 2005 15:34

RE: FMIPv6 - SPI in FBU for handover keys

I agree. This seems better than making it specific to FMIP. The FMIPv6 revision can probably state that this
option is mandatory in the FBU. 

Vidya

> -----Original Message-----
> From: James Kempf [mailto:Kempf <at> docomolabs-usa.com] 
> Sent: Thursday, August 04, 2005 7:20 AM
> To: Charles E. Perkins; Vijay Devarapalli
> Cc: Narayanan Vidya-CVN065; 'Gerardo Giaretta'; 'Julien 
> Bournelle'; mipshop <at> ietf.org; 'Rajeev Koodli'; Venkitaraman 
> Narayanan-CNV002
> Subject: Re: [Mipshop] FMIPv6 - SPI in FBU for handover keys
> 
> 
> I like the idea of an SPI. It would allow us to name the SEND 
> key with something other than the address.
> 
>             jak
> 
> ----- Original Message -----
> From: "Charles E. Perkins" <charliep <at> iprg.nokia.com>
> To: "Vijay Devarapalli" <vijayd <at> iprg.nokia.com>
> Cc: "Narayanan Vidya-CVN065" <vidya <at> motorola.com>; "'Gerardo 
> Giaretta'" <Gerardo.Giaretta <at> TILAB.COM>; "'Julien Bournelle'" 
> <julien.bournelle <at> int-evry.fr>; <mipshop <at> ietf.org>; "'Rajeev 
> Koodli'" <rajeev.koodli <at> nokia.com>; "'James Kempf'" 
> <Kempf <at> docomolabs-usa.com>; "Venkitaraman Narayanan-CNV002" 
> <Narayanan.Venkitaraman <at> motorola.com>
> Sent: Thursday, August 04, 2005 4:28 AM
(Continue reading)

Permalink | Reply | 1 comment |

Gmane