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

Re: an SPD syntax example



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