james woodyatt wrote:
e.g. RFC 3041, SEND, et cetera.
For example, RFC 3041 is *very* easy to fix.
Where it uses "upper 64 bits" and "lower 64 bits", change it to upper
(length(ii)) bits, and lower (128 - length(ii)) bits.
If the II happens to be 48 bits, the upper 48 of the MD5 become the new
temporary II, and the lower 80 become the stored value.
The "fixed" II 48 + stored 80 become the new 128 bits used as input to
MD5 on the next cycle.
One observation related to 3041: having what is effectively VLSM, makes
it orders of magnitude more difficult to first identify the location of
the network/host split, on mixed traffic sniffed at random locations on
the internet.
Fixed /64 size makes finding the split point (network vs II)
tautologically trivial - it's always after bit 64.
If sniffing/tracking is targeted, it becomes considerably easier to
identify sources, e.g. if initial value of EUI-64 is known.
It becomes a deterministic sequence of II's. And once one II value is
found, subsequent sniffing is equally trivial.
If, on the other hand, the *size* of the II is unknown, or even better
changes over time, each step in the search sequence goes from
one step, to as many as (128 bits - 48 bits smallest II size - 3 bits of
Unicast space = 77 bits) 77 choices to make for the next II values
that might be used.
(RFC 3041 should have included randomly rotating the bit-field before
selecting N bits, to handle the determinism. But it doesn't, so for any
II, the sequence is fixed.)
Which RFC is SEND, again?
Are there any RFCs you know of offhand that rely on 64-bit II? I'd
really like to address them in my forthcoming I-D.
Thanks.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
