[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
"in-band" is wrong idea/terminology
> From: ashar@osmosys.incog.com (Ashar Aziz)
> I have an issue. I would like to be able to do in-band signalled
> keys.
When I first read this, I thought I understood that you meant "using IP"
by "in-band" (the usual use of the term). That is, no external
non-internet technique is used. That is quite clearly correct, as a
change of SAID signals a change in keys.
Then, a later message says "zero-message". This makes no sense, as it
is impossible to provide an information network without messages.
Now, I perhaps understand that you mean to carry the key management
protocol inside non-management protocol packets, as some parasitic
influence swelling the size of the AH+ESP headers.
> Does the draft preclude this?
The AH and ESP separate key management from authentication and encryption.
The SAID is negotiated and updated by the key management protocol,
whatever that may be.
However, it would certainly be reasonable for the key management
protocol to negotiate the use of a security transform which carries
these parasitic key changes.
However, the MD5, SHA, DES and 3DES transforms currently described do
not carry such information.
> If not, then I believe that
> there is merit in detailing how to indicate in-band keys in the protocol.
You are certainly welcome to write up alternative security transforms
for our enlightenment.
> Note that SKIP is not the only protocol that employs this technique.
> The DEC work also used the same feature (albeit in a different manner).
> I wouldn't be too happy to see AH/ESP protocols preclude in-band keys,
>
As noted above, AH+ESP do not in themselves exclude parasitic key changes.
However, it is fairly unlikely that parasitic key changes would work,
since they would randomly make certain packets much bigger. This, in
turn, would cause fragmentation of full-sized datagrams, which could
result in misordering and duplication. This would cause failure
of the key change, as well as possible confusion when fragmentation is
done by intermediate routers.
Bill.Simpson@um.cc.umich.edu