Re: an SPD syntax example

[Charles Lynn <clynn@bbn.com>]

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.

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.

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.

So I would suggest that the SelectorSet syntax specify local and
remote addresses, which can be a list of single addresses, prefixes
(subnets), or ranges; a protocol or list of protocols; and for each
protocol any additional information -- ports (a list of single values
or ranges), ICMP Type and Code (a list of Types and for each Type a
list of Codes or ranges of Codes), MH Type or ranges of Types, etc.
The translator gets to do the cross-product when translating to the
IKEv2 format, the admin does not have to do it; keeping the policy
the the admin has to look at smaller - an entry can be seen all at
once - makes things clearer, and more apt to express the admin's intent.


There also seems to be possible confusion with the terms "source"/
"destination", "initiator"/"responder", etc.  The first pair is
tied to packets, the second to roles or the peers in the IKE.
One might interpret the latter pair to imply restrictions on which
end can "initiate" a TCP connection (the SYN without ACK) semantic.
Are we saying that there should be one SPD entry to protect TCP
connections that A initiates to B and a second one for traffic that
B initiates to A?  Note that this is distinction is muddied by the
fact that most current TCP applications use well-known ports in a
client-server model; specification of ports is currently overloaded
with directionality.  TCP is really peer-to-peer; it would be
unfortunate, in my opinion, if the IKE syntax were to encourage
administrators to block emerging services because they cannot
specify the policy that they want.  It is the old chicken and egg
problem -- new apps cannot be deployed because of artificial limitations
elsewhere, and since they cannot be deployed, there is no "user demand"
for them.  I would suggest using "local"/"remote" or some such terms.
The current syntax does not really bind "sourceAddr" or "destAddr" to
"inbound" or "outbound".

Example: could "insiders" circumvent an admin's policy by initiating
a TCP connection *from* port 20 *to* a remote port 4567 (many folks
are "admins" on their desktop systems)?  I think that removing the
"inbound" and "outbound" tags for two-way flows opens up this hole.


As I just mentioned in my message "IKEv2 changes", I think that there
should be text describing how unidirectional policies should be
encoded in the current syntax. I would suggest saying that the ICMP
sender's end should specify the Type and Code in the "initiator's"
traffic selectors, and that they should be "OPAGUE" in the
"responder's".  It should be part of the ASN.1 syntax for ICMP Type
and Code, and Mobility Header Type.

I would add ANY and OPAQUE to the 2401bis syntax as CHOICEs.  2401bis
is the architecture document, intended for administrators as well as
implementors, so I think adding text that exemplifies things of
interest to the admins is beneficial.  (Please respond re: ASN.1 being
easy for folks to understand to /dev/null :-)  The standard conformance
test is any implementation that exhibits the external behavior, so
there is no requirement that an implementation have a one-for-one
mapping.

I would make protocol a list, as that is how admins think of it;
again, let the software do the cross-products, not the admin.

> Note, that in most cases the code 0 is reserved,
> thus it cannot be used as special ANY value.

Actually, it is the cases where it is not "reserverd" that cause the
problem, i.e., protocol 0 is the Hop-by-Hop extension header.

If one defines ANY as a *range* whose "start" value is 0 and whose
"end" value is 2^^n-1, then the range 0..0 should be distinguishable
from ANY.  Protocol is the problem, as IKEv2 does not allow it to be a
range.  I can see wanting to indicate fragments for any protocol, but
then the Fragment Header is the "protocol" and ANY would be the
protocol specific additional information (aka IKEv2 ports) which
allows a range. That still leaves how to express the policy "all
traffic between A and B".  One could use the (currently) reserved
value of 255, or request that IANA assign a value to get around
IKEv2's syntactical limitation.  <CrockAlert> Note that protocol 61 is
assigned to any host internal protocol, which should never (FLW) be
sent between hosts, so it might be possible to overload
it. </CrockAlert>

Re: combinatorial explosion:
> I don't recall the example in detail, but it seems unlikely that, in 
> practice. one would need to send such a big TS payload.

The conclusion seems to be saying that the admin can work around the
problem by creating multiple SAs that protect subsets of the desired
traffic.  If a policy is to be applied to many types of traffic,
having to use multiple policies, which as currently defined, implies
multiple SAs, does not seem like a good idea from the policy
management perspective.  Then there is TFC - using multiple SAs
instead of one decreases the level of TFC that one can achieve.

Comments?

Charlie