[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: clarification
> > opaque has been removed so that freedom is no longer possible.
> "Opaque" is still a SHOULD, so the correct statement is...
Besides, even if "opaque" *had* been removed, that part of the draft is
quite clear that it is specifying *minimum* functionality... so an
implementation which feels that it has a need for extra power in its
SPD can always provide it.
> I have also heard the opaque should be defined...
Agreed; context tends to make its meaning clear, but that's not a good
substitute for an explicit definition.
> However, the IPSec DOI does not currently specify a way to express
> OPAQUE (maybe one could define 65535 to mean OPAQUE port and 255 to
> mean OPAQUE protocol), so there is an inconsistency here that should
> be addressed.
I don't understand the inconsistency. How "opaque" is expressed in
databases and/or data structures within an IPSEC implementation is an
implementation issue. "Opaque" is not an actual port/protocol value -- it
never appears in a packet on the wire -- so there is no need for the RFCs
to tell you how to express it. The only fact that needs to be pinned down
is that it must compare unequal to any actual value (which means that it
can't be 65535, unless it is illegal for a TCP/UDP implementation to use
65535 as a real port number, and I don't recall that being the case).
Henry Spencer
henry@spsystems.net
(henry@zoo.toronto.edu)
References: