On Apr 22, 2014, at 2:29 PM, Guy Harris <g...@alum.mit.edu> wrote:
> In addition, the code *still* has a preference to indicate whether the octet
> preceding the mode/LLID is just 0x55 or an encryption enabled/key ID field.
> Either
>
> 1) there should be *two* LINKTYPE_ values - LINKTYPE_EPON, in which
> that field is just part of the preamble, and LINKTYPE_DPON or
> LINKTYPE_CABLELABS_DPOE, in which it's an encryption enabled/key ID field
>
> or
>
> 2) if that field will *never* have the value 0x55 in a DPoE capture,
> and will *always* have the value 0x55 in a regular EPON capture, use that to
> determine what the field is.
According to
http://www.cablelabs.com/wp-content/uploads/specdocs/DPoE-SP-SECv2.0-I03-140327.pdf
(BTW, 5 googolplex cheers to CableLabs for not putting their specifications
behind a @#$%@@$$# paywall!), the octet before the LLID will always have the
bit value 010101EK, where E is the "Enc", or "data transferred is cypher text"
bit, and "K" is the "key identification number used to encrypt the frame", with
the number in question being either 0 or 1, obviously.
So a value of 0x55, i.e. 01010101, has the "data transferred is cypher text"
bit clear, and the "key identification number" bit being 1 but presumably being
*irrelevant*, as the "data transferred is cypher text" bit is clear and the
frame is *not* encrypted.
Furthermore, the spec also says "When encryption is disabled, the DPoE System
MUST set the 1Down security octet to a value of 0x55."
So is there any technical reason *not* to dissect the frame by:
if that octet doesn't have the upper 6 bits as 010101, report it as an
error;
if that octet is 0x55, show it as a preamble octet, and treat the frame
as not encrypted;
if that octet is 0x54, report it as an error, as encryption is disabled
but the security octet is *not* 0x55;
if that octet is 0x56, report it as "encryption enabled, key ID 0", and
treat the frame as encrypted;
if that octet is 0x57, report it as "encryption enabled, key ID 1", and
treat the frame as encrypted;
with no preference needed?
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
