Re: an SPD syntax example

[Stephen Kent <kent@bbn.com>]

At 12:19 -0500 2/2/04, Charles Lynn wrote:
>Catching up...
>A few comments on the ongoing SPD syntax discussion, IKE, and 2401bis.
>
>>It is better to make this as close to IKEv2 Traffic Selector as
>>possible.
>
>I disagree :-) ... on the grounds that clarity and simplicity for the
>administrators promote better security.

Good point; clarity is better, so long as it is easily mapped to 
IKEv2 TS payloads.

>I think that the syntax should be designed to encourage a clear and
>concise specification of the types of traffic that should be protected.
>We should not be using a syntax that lets an administrator enter
>information that is non-sensical or inappropriate, as much as possible.
>The "software" can translate that format into whatever the key management
>protocol(s) use internally; the programmer only has to get the translation
>right once, the admin would have to do it for each SelectorSet.

yes, but let's keep the translation easy, or it will be done improperly.

>As an example, the IKEv2 syntax (which is an improvement over IKEv1,
>and which I do not think needs to be changed -- but does need to be
>"clarified") allows one protocol to be specified in the initiator
>traffic selectors and a totally different one to be specified in the
>responder traffic selectors -- something that is clearly wrong.

agreed. good example.

Firewalls distinguish between connection initiators and responders, 
but that may not be critical here, since that we have authentication 
for SA establishment, and integrity mechanism for continuous 
protection after SA establishment. So, for SAs the asymmetry may not 
be an issue.  Note that the current syntax I suggested does retain 
inbound vs. outbound distinctions for non-IPsec traffic, where we 
lack the protections noted above.


Let me suggest that you prepare an ASN.1 syntax example that meets 
the criteria you described in your message and bring it to the list, 
along with the explanation of how to map it to IKE TS payloads. We 
can work from there.

Steve