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

Re: My current thoughts on IPSEC


From:  Ran Atkinson <atkinson@bodhi.itd.nrl.navy.mil>
In-Reply-To:  "Donald E. Eastlake 3rd (Beast)" <dee@skidrow.lkg.dec.com>
	             "My current thoughts on IPSEC" (Mar 31,  6:25)
References:  <9403311125.AA01325@skidrow.lkg.dec.com>
Reply-To:  atkinson@itd.nrl.navy.mil
X-Mailer:  Z-Mail (3.0.1 23feb94)
To:  "Donald E. Eastlake 3rd (Beast)" <dee>
Sender:  atkinson@bodhi.itd.nrl.navy.mil

>Don,

(Ran, thanks for permission to include your personal mail to me in
this response to the list)

>When we looked into encapsulating security packet formats for SIPP, we
>found that the flag bits and such like didn't really need to be
>explicit or defined on a per packet basis.  Instead, the
>presence/absence of options for all packets of a particular session
>can be implied by the SAID value in the same manner that the SAID
>value already implies an algorithm/mode/key.  I am not recommending
>putting any meaning into the bits present in any SAID; I think the
>SAID always should be a completely opaque identifier.  Also, it might
>be useful to indicate that the SAID might be directional (e.g. A-->B
>uses SAID 1 and B-->A uses SAID 5) because this eliminates the need
>for direction bits.

I understand the simplicity of encoding everything in the SAID but
there are capabilities you just can't get that way.  There are a
number of reasons for clear header information.

For accounting / filtering purposes, you want to know if encryption is
being used so you can look deeper into the packet when its not.  Thus
you need a clear encrypted/non-encrypted bit.  (Of course having
separate authentication and encryption encapsulation also solves
this.)  You could incorporate this into the SAID and have just an
informational bit but I wouldn't bet it would be properly implemented
unless you spec that the clear bit actually *controls* whether
encryption is used or not.

My protocol tries to handle isolated datagrams and broadcast/multicast
as well as the negotiated point to point tunnel type thing and I think
it useful to distinguish between these outside the SAID field.  This
is logically necessary if you have datagram SAIDs globally pre-defined
by standards actions, multicast SAIDs relative to the sender, and
negotiated unicast SAIDs disjoint from both other cases, as I have.

In the higher level implementations, my proposal provides for options
in either the clear or encrypted headers or both.  For some types of
global SAIDs (ie, datagram without set up), the encryption keying
information is determined from a destination identity that is
different-from/finer-grained than an IP address.  The destination host
needs to be able to see this destination identity in order to be able
to decrypt (or pass it on to the right party who can decrypt) the
encyrpted header.  Therefore provisions for this optional type of
destination identity must be made in the clear header.  There are also
provisions for security labeling via options in the clear header
(authenticated but not encrypted) and well as the encyrpted header or
both.  Because many packets will not have any options (and lower level
implementation need not provide for them other than to return an
error), there is a clear header options-present bit so you don't waste
any bytes when there are no options.

I also included an optional time stamp so you need a bit to say if it
is present or not.  This bit and time stamp could have been in the
clear or encyrpted header.  They need to be authenticated but there is
no need to encyrpt the time stamp.  If present, its just the "current"
time.

I don't think I have any direction bits right now.

>Did I miss the "crypto-synch" optional field in my quick scan of the
>packet format ?  If there isn't one, it needs to be added to ensure
>algorithm-independence.  SP3 called it a PAD field just before the
>encrypted data; NLSP admitted that the field was for crypto-synch but
>kept it in the same location.

I disagree.  I believe that cryto "synch" "pad" "ivp" etc. fields are
all logically part of the cyrpto algorithm.  Why explicitly label such
fields when some low level algorithms need them and some don't?  It
just makes everything look more complicated and makes things you seem
to think of as outside the crypto algorithm dependent on the crypto
algorithm.  In my mind, an encryption algorithm, for example, takes in
data and a key and outputs data such that the corresponding decyrption
algorithm with the corresponding decryption key recovers the original
data.  It should be of no concern to IPSP whether the encrypted data
actually starts with a crypto-synch or whether the pre-encryption data
had to be padded or if that padding was at the start or end of the
data.

>Based on discussions with various members of the community and also on
>the output of the IAB Security Workshop, I'd like to suggest that we
>consider decoupling the "authentication tail" into a separate
>mechanism that can either stand-alone or be used with the
>encapsulating security header.  There is no technical merit in such a
>split, but there is substantial commercial/user value in having an
>exportable authentication-only mechanism.  The only reason that SIPP
>has two headers (Authentication Header & Encapsulating Security
>Payload) is to ensure that we can universally implement and deploy at
>least authentication-only in the Internet.

I am not completely decided on the merits of this; however, I believe
the export argument is specious.  If you have a compile time switch to
turn off the confidentiality code and export binaries with only
authentication, there is no problem.

>I like the effort to ensure that the mechanism is easily implemented
>in software.  That is important to having widespread deployment and
>use.

Thanks.  I tried to take into account the lessons the Phil Karn has
learned from implementation thus far.

>Ran
>atkinson@itd.nrl.navy.mil

Donald