Re: new version of ESP ID

[Andrea Colegrove <acc@columbia.sparta.com>]

Steve,

Stephen Kent wrote:

> >
> >Are there plans to expand the SPD facility to support more generic policy, as
> >well?  It appears that while RFC 2401 designates IKE as the default security
> >management mechanism, allowing others, as a "MAY", multiple
> >management mechanisms
> >may be needed for different uses. (e.g., IKEv2 for gateways, JFK for
> >small mobile
> >devices, gdoi for single source multicast groups, KMI for
> >government, etc.)  These
> >mechanisms may also have different policy needs.  For example, GDOI
> >might want to
> >check that it has received out-of-band, a group policy token that is
> >valid before
> >proceeding to key distribution.  It would probably be important to
> >show that the
> >correct management mechanism is selected according to policy and
> >that the security
> >operating assumptions for each is met.
>
> IKEv2 and JFK are competing replacements for IKE v1. I don't see the
> split you allude to above, i.e., I expect the WG to select one
> replacement, because the choice affects not only the local device,
> but also any device with which it communicates. So a I can't have one
> protocol for security gateways and another for small, mobile devices,
> if these devices ever want to communicate with a computer behind a
> security gateway, for example.
>
> Nonetheless, your question is relevant. There is a distinction
> between what 2401 will mandate in terms of SPD capabilities, and what
> any key/SA management protocol provides. I think it is reasonable for
> IPsec to be able to use more than one key/SA management protocol, but
> the SPD should be uniform and the protocols should support what the
> SPD allows users to express. The concern I have re support of
> multicast is any imposition of new requirements on the "fast path"
> processing required of all IPsec implementations. As more of these
> move into hardware, to accommodate higher speeds, we cannot easily
> make changes on things such as SA demuxing without severely affecting
> this hardware.

Re:  IKEv2 and JFK -- a couple of recent postings have mentioned the use of both.
But, yes, I agree it would be an interoperability nightmare.

Nevertheless, even the different domains of pairwise dynamic keying, single-source
multicast, multi-sender multicast, pre-placed (if it survives) update management,
and centralized keying, all have slightly different needs for the SPD.  I would
suspect that unless the policy issues were pushed up to the application layer, that
the SPD will need to have a flexible format for any implementation.  Indeed, I
would suspect that for management purposes, it would even make sense in the future
to take on standardized approaches for remote management of SPDs.  (2401-bis).

This complexity probably does fly in the face of the simplicity needed for high
speed applications.

--- Andrea