RE: Resend: Re: [LinkSec] Proposed Scope for LinkSec PAR
Russ,
Didn't mean to suggest that you were against the Ethertype, just wanted to
get this out early on for all. Don't want to spend time trying to cope with
specifying two formats - now there's a source of errors even if one is never
used.
Talking of implementation errors, I bet you are even more subject to
questions of the form 'how do I make this incorrect or partial
implementation of the protocol do all the protocol does, without
implementing all the protocol correctly and removing all the incorrectly
added parts' than the rest of us.
Mick
-----Original Message-----
From: Russ Housley [mailto:housley@vigilsec.com]
Sent: Friday, May 09, 2003 11:11 AM
To: mick_seaman@ieee.org; 'LinkSec'
Subject: RE: Resend: Re: [LinkSec] Proposed Scope for LinkSec PAR
Mick:
>If the secured frame format does not use an Ethertype instead of a SAP then
>some company or companies will have to band together to produce an SFF
which
>does use an Ethertype (the only sensible way to cope with overlength
>frames). This SFF will then be usable for frames that satisfy the proper
>size limits, so will simply be the only one deployed.
I am not objecting to use of an EtherType. In fact, when I worked on an
Ethernet encryption device at Xerox, we used an EtherType. However, this
approach was not acceptable to IEEE 802 at the time that SDE was
developed. I am glad to see that EtherType is no longer in disfavor.
>By chosing a new Ethertype we will be able to remove any traces of
>historical baggage, and will not have to allow as optional items that need
>to be mandatory. Options are an invitation to lack of testing and lack of
>interoperability, and should be avoided if at all possible.
In general I agree. Options lead to complexity. Complexity leads to
implementation errors. Implementation errors in a security protocol lead
to insecurity.
Russ