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 |
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 |
headers
Christian Vogt | 19 Oct 2005 15:41
Picon
Favicon

Re: larger options

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

All Mobile IPv6 variants should have incorporated mechanisms to
determine that all parties involved do in fact support the variant.

Furthermore, it would be possible to require in the variant's
specification that oversize options must be supported.

These things said, and given that standard Mobile IPv6 does not use
options of size 255, defining option length 255 to indicate oversize
would be possible, too, existing implementations notwithstanding.

Nonetheless, I do like option concatenation.  It seems to be the only
feasible approach for Mobile IPv6 variants which are unable to determine
in advance that both peers provide the required support.

If I was asked to give a statement on this, I'd say:  Write a document
for oversize options, but leave it to the discretion of Mobile IPv6
variants whether they depend on that oversize document or use option
concatenation instead.

- Christian

--

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/
(Continue reading)

Permalink | Reply |
headers
Francis Dupont | 22 Oct 2005 10:51
Picon
Picon

Re: [Mipshop] larger options

 In your previous mail you wrote:

=> this issue was solved by adopting the concatenation idea:

   > o    The truly long options are rare, there's likely just one (cga). 
   > 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(...)
   > 
   > --Jari

I can't see a good reason to reopen the issue as the solution works
and needs no new document.

Regards

Francis.Dupont <at> enst-bretagne.fr
Permalink | Reply |
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 |
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 |
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 |

Gmane