Re: draft-ietf-ipsp-ipsec-apireq-00 comments

["The Purple Streak, Hilarie Orman" <ho@xxxxxxxxxxxx>]

I think the "motivation" section, even with the edits posted by
Bill Sommerfield, remains sufficiently unclear as to probably baffle
most of the WG members.  This, absent the minutes of the interim
meeting held at the beginning of summer, makes it difficult for
the WG to comment on the draft.  In positive terms, what is the
motivation for the API?  We need to get this right before asking the
WG if this should be taken on as a WG item.

The draft states that it should be possible "to implement this" (the API?)
with IKEv1, IKEv2, KINK, ..."  This seems to be verging into architecture,
and I'm knot sure what the exact goal is.  Is it that the API should
have a mapping to any protocol that support IPSec keying?  What are
the essential attributes here?  Is identity the only one?  Later, the
draft talks specifically about IKE SA's, implying that the API might have
additional dependencies on the key management.  We need more generic language
to get the requirements right.  However, I think that IKEv{1,2} MUST be
supported.

What is the relationship of the API to IPSec structures, such as SA's, SPD's,
etc.?  This would be the explanation of the statement "system policy
trumps all", I would guess.  There seems to be an implication that
applications have security policies that map to things specified by 
the API reqs.  An explicit statement of this would help motivate
the need for the API.

The requirement that "nominally authorized" communication failures be
visible to the application needs additional thought.  Presumably these
are communications related to a socket for which the application has
some authorization (how fine-grained is such authorization?).  Should it
see failures on incoming packets that fail the integrity check?  These
may be spoofed, and the system policy may forbid applications to see
them.  MUST the API reveal these?

I personally disagree with the HOW section.  This is an API for IPSec
policy, and all identifier names used in IPSec should be fair game
for the API, down to the awful algorithm names in their full glory
and including IKE key exchange methods and group names.

Hilarie