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

Re: SAIDs and formats



Steve,

>	The algorithm-dependent control info that Ran was referring to
>is variable on a per-message basis,

Yes, I agree.

> and thus cannot be subsumed by
>reference through the SAID. For example, a encryption mode that
>requires a per-packet IV or padding that is required to match an
>algorithm's block size would go in these areas. 

No, I disagree, there is nothing to stop the SAID referencing via a 
record, a procedure which knows the location in the message of these 
fields and can perform appropriate padding etc on a per message basis. 

In summary, a receiver's implementation could have the following 
distinct pieces of code:

1) code for common clear header analysis and processing, (always used)

2) code for security processing, (implied by SAID).  There may be a 
number of these pieces of code implemented in a system for different 
security schemes but the SAID will imply the use of only one at a time.

3) code for interpreting and processing the result of (2).  This may be 
the same as (1) in all cases as with the current proposal.  However 
alternative formats (e.g. authentication data or a compressed header 
format) could be implied by SAID, independent of (2).

What I am suggesting is that the specifications of the three parts be 
unbundled so as to ease future independent enhancement with new 
security schemes or different protected data formats.

>	The SAID will indicate which services are employed and so it
>can be used to indicated wether encryption and/or integrity checking
>transforms have been applied.  However, if the representation needed
>for integrity for all traffic (as a default), and which is intended to
>live in the IP header, conflcits with some of the requirements for an
>explicit IPSP layer, then using different IDs seems approriate.

This may be the case, but I thought I heard agreement last week that 
the IP6 security formats would not be constrained by IP4 format 
requirements. The only constraint was to be the use of the same 
security mechanisms in both cases.


Antony

(I'm having my computer surgically removed for the next two weeks for 
my summer holiday -> no response does not mean I'm sulking! :-)