[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SKIP with AH/ESP/etc.



Folks,

Hilarie Orman has proposed an excellent alternative protocol to
integrate SKIP with the AH/ESP protocols which is in many ways superior 
to what we proposed at the Stockholm SKIP BOF. Since there was clear 
consensus at the last BOF to make SKIP a standards track protocol, I 
would like to make sure that there is group consensus on this 
alternative SKIP protocol header before we publish it in the next
revision of the SKIP draft. 

Hilarie has proposed that we separate SKIP key-mgmt info
from transform specific information (e.g. IVs, MACs etc.)
and place this in a separate SKIP header that precedes
the AH/ESP headers. SKIP would need its own protocol number,
and would contain a next header field which would indicate
AH or ESP. There are actually other possibilities as well,
which I will describe below.

A figure (courtesy of Paul Lambert) illustrating this is as 
follows:


>        +---------------------------------------------------------+
>        |  IP Header (Next Header == SKIP)                        |
>        +---------------------------------------------------------+
>        |  SKIP Header with key mgmt data but w/o the             |
>        |  transform data (such as IV) and NextHeader=(AH/ESP/etc)|
>        +---------------------------------------------------------+
>        |  ESP or AH exactly as per RFC-1825-1829 but with a SPI  |
>        |  value that is from the reserved SPI space and is       |
>        |  assigned to mean (look at the preceding SKIP header)   |
>        +---------------------------------------------------------+ 

The big win here is that all of the current proposed standard
RFCs 1825-1829 can be used directly with SKIP key-mgmt without 
making any new protocol transforms specific to SKIP. This includes
the DES-CBC and the key-ed MD5 transform as currently specified.
Any new transforms defined can be similarly accommodated.

This also makes possible the use of SKIP with other protocols
that also need keying material, without modifying the protocols 
themselves. The SKIP nextheader field would simply specify those 
protocols. Some examples of this are routing protocols
that use keyed MD5 (and dont need/use AH for this purpose).
(Thanks to Cheryl Madson for pointing out the need/possibility
of these other alternatives).

Because this is a much cleaner and simpler way to integrate
SKIP with AH/ESP (as well as other protocols that may need
keying material) I am inclined to adopt Hilarie's suggestion
and specify this in the next draft of SKIP (due in a week
or so from now).

Please let me know if people have strong opinions on this,
either for or against.

Thanks,
Ashar.






Follow-Ups: