Re: Son of IKE: A proposal for moving forward

[Stuart Jacobs <stu.jacobs@xxxxxxxxxxxx>]

If this group restricts their focus primarily on the VPN scenarios below 
then they are ignoring a major role that IPsec is expected to fill by large 
enterprises.

Verizon is in the process of developing the security architecture for it's 
next generation networks.  Given the magnitude of these networks and FCC 
requirements for open access, we must have the ability to universally 
establish strongly authenticated identities of communicating network 
elements.  This authentication must be able to span many trust domains, be 
continuous to avoid any chance of session hi-jacking and scale to millions 
of nodes.  IPsec, coupled with PKI, is the only technology that can even 
begin to meet our needs.

We are relying on this WG to include in it's scope mechanisms that allow 
two network elements, regardless of their functions within a network, to be 
able to use IKE and ISAKMP, with PKI based X.509 certs, to establish one or 
more SAs that these two elements can then use to continuously authenticate, 
and optionally encrypt for confidentiality, UDP, TCP or SCTP transport 
layer communication sessions.  This fundmental capability is critical for 
our use of IP technology for the transport of SS7 traffic, VoIP application 
signalling, (G)MPLS control plane signalling and OAM&P traffic.

Without the ability of using IPsec we will be forced to use stove-pipe TSL 
methods that rarely interoperate, have never been proven to scale the the 
number of subjects we must contend with, will significantly increas 
complexity of operational controls, and increas management expense.

Stu Jacobs
Verizon Network Security Architecture


At 6/12/02 01:02 PM, you wrote:
> At 9:43 AM -0700 6/12/02, Michael Thomas wrote:
> > The one thing I don't see here is any
> > consideration of the very basic question of
> > whether there are in fact two different problem
> > spaces.
>
> There are certainly more than two.
>
> Michael is correct here in that we cannot evaluate the WG questions for 
> the general problem of keying all possible uses of IPsec. Well, we can 
> try, but it would be a waste of time (but typical of many IETF Working 
> Groups...). At the end of the effort, we would probably have no general 
> agreement on the significant questions.
>
> Having said that, and showing my obvious bias towards VPNs, I propose that 
> as we answer the questions, we do so with today's VPN customers in mind. 
> These folks mostly do two things:
>
> a) gateway-to-gateway, with each gateway possibly connecting to many other 
> gateways
>
> b) access over modems (or faster) from remote single-user computers
>
> Let's get SOI done right for these customers.
>
> Doing so doesn't prevent work from a different key exchange mechanism that 
> addresses a different use case; the most obvious one that probably won't 
> match with the use case above is remote access where there is a need for 
> very quick keying, or where the remote parties have relatively slow CPUs, 
> or where the remote parties have only small amounts of program memory, or 
> some combination of these.
>
> The work we have done in the past few months can help focus the feature 
> sets for each of these efforts, as well as for other efforts that might 
> arise later. But let's not pretend that we can do it all at once in a 
> single protocol -- we know we can't, and we have good evidence that we can 
> waste a lot of time trying.
>
> --Paul Hoffman, Director
> --VPN Consortium

==========================
Stuart Jacobs CISSP
PMTS - Sr. Technologist
Verizon Laboratories
40 Sylvan Road Waltham, MA 02451-1128     USA
telephone: (781) 466-3076   fax: (781) 466-2838
stu.jacobs@xxxxxxxxxxxx sjj0@xxxxxxxxxxxx  stu.jacobs@xxxxxxxxxxx
==========================