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

Re: (IPng) More Endpoint Attributes



> From: Theodore Ts'o <tytso@MIT.EDU>
> Cc: ipsec@ans.net
> Subject: Re: (IPng) More Endpoint Attributes  
...
> 	You seem to be making an assumption that you need a different
> SAID to represent a different SA every time the attributes associated
> with a SA changes (or "modulates", using your terminology).  
> 
> 	If it is only the attributes associated with an SA which are
> modulating, while the SA remains constant --- since a SA lasts the
> lifetime of a TCP connection --- why can't the SAID remain the same,
> since it is still the same Security Association.  True, the process
> privilege set may be bouncing up and down, but if it's the same security
> association, it should be the same SAID.  It's only the attributes which
> are changing.

This is a very good issue.  As you said, "the process privilege set
maybe bouncing up and down".  When the receiver reads data, it may want
to know if the data was sent when the privilege set was up or if it was
down.  If the data was a request, the response to the request may very
well depend on what prvileges were in effect when the request was
sent.  For example an X-server may look at the privileges in effect
when when an X_GRAB request was sent to determine if the client is
acting as a privileged entity to get data to scale a display or if the
client is acting upon a request from the user who maybe trying to use
the X-server as way to bypass system policy.

The only way to tell the receiver if the privileges were up or
down when the data was sent is to include that information along
with the data in the packet.  In otherwords the privileges must
be tied with the data.  It isn't possible to send the privileges
using a separate protocol because there isn't any way to mark
in the data stream when a privilege change occured.

The only thing in the current draft that can be varied to convey a
change in privilege is the SAID.  It appears the current architcture
views SAIDs as statically assigned things that persist for the life of
the connection or longer.  If a SAID is the only thing available to
modulate when the privilege state (or other attributes) modulates,
we'll have to modulate it.  Unfortunately modulatings SAIDs doesn't
look like it will work very well.

Probably a better idea would be add some additional fields that can be
modulated as attributes modulate.  Adding an optional sequence of
type-value pairs after the AH header would give something to modulate
while holding the SAID constant.  A SAID definition can specify what
types should be included with the each packet.  Many SAIDs may not
include any additional type-value pairs.  Some may include many.  Some
may only include a type-value pair when something changes.  Types
probably should be 16-bits and values can be 32 bits (48 might work
better).  Take 10 bits of the reserved field in the AH header and make
it a count of the number of type-value pairs included in the header.
Then add that many 16-bit type and 48-bit value pairs after the fixed
length header.

Dean Throop		throop@dg-rtp.dg.com



Follow-Ups: