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

Re: SAIDs and formats



Steve,

<	I'm a bit puzzled by your diagram, since it doesn't match the
<one Ran sent earlier this week.  Ran's showed algorithm-dependent (and
<thus SAID-specified) IPSP control info both immediately after the SAID
<and after the encapsulated protocol.  However, I didn't attend the
<IPv6 meeting ypu refer to, so there is opportunity for confusion here.

	The algorithm-dependent IPSP control info both immediately after the SAID 
and after the encapsulated protocol which Ran showed in his diagram I had 
incorporated in the records indexed by the SAID at the receiver which specify 

"How the mechanisms are to be applied to the data (order of mechanism 
          application, range of data to be processed, **location of 
	  Algorithm-dependent init stuff** etc)"

	This information also has to available to the sender of course.

	I am not seeking to alter the internal format proposed by Ran, but for 
clarity to separate the descriptions of the three parts e.g. the description of:

1) The information which the routing system sees for handling the clear packet
   fields (? + SAID).

2) The variable length 'random' data in the packet which is used by the security
   mechanisms, either for their own purposes (algorithm-dependent IPSP control
   info both immediately after the SAID and after the encapsulated protocol) or
   to be processed by them and delivered as the result of the security
   processing.

3) The format of the resulting data after security processing (which now has some
   security assurance associated with it) to enable further processing. 


>	I believe the plan was that there would be two different
>protocol IDs used: one for authentication (really integrity with
>authentication based on key distribution) only, which will be carried
>in the IPv6 header, and one for confidentiality and/or autehntication
>and integrity, which will come after the IPv6 header, i.e., as a
>legitimate next protocol layer.  Perhaps the header length format (and
>thus size) constraint you described applies only to the first of these
>two?

	Your thoughts align completely with my understanding of the current 
proposals.  My point was that with a 'minor' change, one protocol id could 
perform both functions because the SAID would imply the distinction between them 
(which may be blurred in some cases).  This change would give the 'advantages' 
of:

1) less differentiation of security information which might aid an attacker

2) it might simplify the security processing by have a single SAID space to 
manage rather that the potential for two.

3) greater flexibility in the use of the security payload by allowing more than 
one (not a particularly good reason because you could put two into one anyway if 
you really wanted to do this)

4) allow flexible mixing of protected and unprotected data in the same packet in 
any order

5) it seemed more elegant to me.


Antony