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

Re: Comments on Tuesday's meeting


I tend to agree that using optional fields is probably a better way to
go, but complex TLV encoding should be avoided.  Using an internal identifier
(internal to the packet, or inferred by the SAID) that specifies which
security services have been selected and in what particular format/order they
exist (ISN->ICV->Data->Pad, ISN->DATA->Pad->ICV, etc) would provide
this functionality in an efficient manner.  Sort of a packet identifier
within the IPSEC packet.  This way we would only, 1) have to agree on a
standard header format, and 2) have a table of recognized data format 
types (with room for expansion/private use).

Example table:

Data Format Type Value		Format

 0000 0001			DATA+PAD+ICV
 0000 0010                      ENC-DATA+PAD+ICV
 0000 0011                      ENC-DATA+PAD
 0000 0100                      ENC-DATA+PAD+TrafficPad
                    .
                   . 
                   .
    		  ETC.

(BTW, DATA is an entire IP packet)


One problem that I can forsee with a standard header format (and was
brought up at the Tuesday meeting) is the issue of CPU vs. Bandwidth
efficiency.  For low bandwidth networks, padding for word-boundary
efficiency is not acceptable, but for high speed, high bandwidth
networks it is extremely desirable.  So it would seem that we need a
very efficient (for both worlds) and fairly flexible packet format
(forgive me for stating the obvious).  The above should provide the
flexibility and efficiency for the data portion of the packet.  I don't
think we have agreed on what the header should contain (other than a
SAID) let alone the header format.  Should the SAID be fixed in
length?  If so, what is the length?  I'd like to propose something like
the following VER+H-LEN+SAID+OPTIONS.  The VER is included in case we
don't get the packet format perfect the first time (ie. requirements change).
The OPTIONS field would only need to be processed if it is present 
(similar to IP).  Options could include keys, sequence numbers, padding, 
special flags, labels and anything else that might be required to meet 
a users special requirements.  

It seems to me that if we are going to have one protocol and one packet,
we need to at least come to some kind of agreement on the packet header.
Anyone care to comment?

Rob G.
glenn@osi.ncsl.nist.gov