Subject: [Mip6] larger options

From: Francis Dupont <[email-masked]>
Date: Tue, 02 Aug 2005 11:34:56 +0200

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

[email-masked]

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?

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Greg Daley <[email-masked]>
Date: Wed, 03 Aug 2005 01:24:07 +1000

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

The second MH could only have Extended length options (except pad?)

I'm not sure if overloading the MH protocol number is too evil.  In that
case, there would have to be an allocation of a new protocol number, and
an admission of the problem to IANA...

Does this sound like a good or a bad idea?

Greg

---

From: Francis Dupont <[email-masked]>
Date: Tue, 02 Aug 2005 18:34:10 +0200

In your previous mail you wrote:

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

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

Regards

---

From: Jari Arkko <[email-masked]>
Date: Tue, 02 Aug 2005 19:47:53 +0300

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

> that following the exlicit length in the MH are "extended" mobility

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

> an admission of the problem to IANA... 

Overloading is usually not so good.

Additional ideas:

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

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
      your real data by setting a flag in the header, and all options
      would use a new format that uses two byte length field for all
      options.

Not sure how good these are either. My current gut feeling is that
I'd go for the option concatenation.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Tue, 02 Aug 2005 19:26:07 +0200

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

   Additional ideas:

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

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

=> this makes a strong assumption...

=> I agree and it makes the solution documentation easier. IMHO it
is workable if oversized options are pretty uncommon.

Thanks