[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Son of IKE: A proposal for moving forward
As an aid to expressing my concerns and needs let me provide a context for
my prior comments.
Verizon is currently developing the architecture for a Next Generation
Network (NGN) that is based on non-TDM technologies. This NGN will serve
as Verizon's core network infrastructure well into the 21st century and
must be a highly available, reliable and trustable infrastructure that will
scale to 100,000s of intermediate nodes, 10,000s of server platforms and
millions of customers across the globe. Given the scaling issues in such a
network we want to use IPsec, coupled with PKI technology, within our
NGN. Although not specifically an IPsec issue, we also have to contend
with different trust domains within Verizon, between Verizon and peer
carriers and between Verizon and our customers and would establish a
hierarchy of CAs for issuing X.509 certificates to Verizon network elements
as well as to Verizon, and non-Verizon, people and organizations.
Our NGN, from a control and management perspective, is a "green field"
deployment and our proposed approach would use IPv6, with mandatory IPsec,
for all control, signaling and management traffic within our NGN
infrastructure. We are concerned with protecting control plane, management
plane and application-specific signaling traffic within our NGN on an
end-node to end-node basis. The protection needed is primarily
authentication with some traffic (specifically billing info, customer
profiles and user application log-in identifiers/passwords) requiring
confidentiality.
We intend to use control plane protocols, such as RSVP-TE or CR-LDP,
between all intermediate nodes. These nodes (such as GMPLS controlled
optical switches, (G)MPLS enabled routers, SONET-ADMs, etc.) will need to
continuously communicate with each other where all exchanged information
must be strongly authenticated. This will necessitate SAs that are
basically permanent yet either re-keyable or replaceable in a controlled
and synchronized manner. The traffic flowing over these SAs require
authentication either by AH or null-encrypted ESP. At this point we do not
see one approach (AH or null-encrypted ESP) as significantly better that
the other. We would most likely use transport mode for efficiency and do
not have to worry about NAT given an IPv6 based addressing and
inter-networking architecture within our infrastructure. Control plane
interaction at trust domain boundaries will utilize an OIF-UNI approach,
not peering, so we can make necessary access control decisions on NGN usage
requests.
Some of our management layer applications (OAM&P) we will be developing
in-house and some of these applications we will be purchasing from
vendors. Our element and network management OAM&P applications operate on
a 7 by 24 basis. Many of our NGN system and business management OAM&P
applications will also have to operate 7 by 24 to support customer and peer
carrier self-provisioning/management dynamic requests. The OAM&P protocols
will include SNMPvX, CORBA, Telnet (with TL1), Xterm, FTP, HTTP/HTML and in
some cases TFTP where unavoidable. The use of XML will grow over
time. Given the wide variety of protocols here we cannot afford to use
protocol specific security approaches that are managed independently and
would be very difficult and expensive to manage and maintain in an
infrastructure as large as our NGN will be. IPsec is the only approach
available that is protocol neutral and centrally manageable.
Since the use of SNMP and CORBA will be continuous between managed elements
and element/network managers we would anticipate using the same type of
basically permanent SAs described above for control plane protocols. The
Telnet (with TL1), Xterm, FTP and TFTP protocols we would want to use with
dynamic SAs that are negotiated at TCP session setup and torn down when the
TCP sessions end. The use of HTTP/HTML and XML would incur significant
overhead if secured via dynamic SAs, yet do not really require use of
permanent SAs, so I would propose the ability to establish semi-permanent
SAs that have a defined lifetime and are torn down when their lifetime is
reached unless recently used within the last XXX seconds or minutes.
Thus we need three types of SAs that can be established between two
communication nodes:
a) permanent SAs that can be established with specified destination nodes,
when either node boots/reboots, and can be rekeyed, or replaced with new
SAs, after specified time periods have elapsed in a controlled and
synchronized manner.
b) semi-permanent, or static, SAs that exist for specified time periods
and can be used by applications. An application needing to communicate
with a corresponding application in another node can request use of a
static SA and the IPsec portion of the protocol stack will use one if it
exists or establish one if none currently exist. When one of these static
SAs has reached/exceeded its specified life-span of time it would be torn
down provided it has not been used within the last XXX seconds or minutes.
c) dynamic SAs that are negotiated at TCP session setup and torn down when
the TCP sessions end. These SAs could possibly exist for long periods of
time (eg. long Xterm sessions or very large file transfers) so they should
be able to be rekeyed, or replaced with new SAs, after specified time
periods have elapsed in a controlled and synchronized manner.
From a usability perspective, there should be some type of data structure
that can be configured to contain default and maximum values for all SAs
created by the network element. I would proposed that some of these values
include:
- maximum SA time before re-keying
- preferred authentication mechanism (AH or null-encryption ESP)
- minimum allowed algorithm for AH
- preferred algorithm for AH
- minimum allowed algorithm for null-encryption ESP
- preferred algorithm for null-encryption ESP
- <similar types of values for confidentiality provided by ESP>
Applications will most likely use a socket based mechanism to establish a
communications path to another network node and should be able to easily
specify the type of SA, if any, desired. I would like to see an
application be able to state it wants no SA, a permanent SA, a static SA or
a dynamic SA used. An application should be able to ask for an SA based
on the network element default values, yet on the other hand be able to
request an SA with values that over ride the network element default values.
Forgive me for possibly being long-winded. My intent is simply to assist
the WG in understanding what kinds of capabilities we want IPsec to
provide. May this serve as input to section 4.3 of
draft-ietf-ipsec-sonofike-rqts-00.txt
Stu
t 6/13/02 12:05 PM, you wrote:
>I urge you to review
>http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sonofike-rqts-00.txt
>and provide feedback. This groups lacks a lot of real-world customer
>feedback and Cheryl would appreciate having any feedback.
>
>jan
>
>
>On Thu, 13 Jun 2002, Stuart Jacobs wrote:
>
> > 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@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com
> > ==========================
> >
>
> --
>Jan Vilhuber vilhuber@cisco.com
>Cisco Systems, San Jose (408) 527-0847
>
>http://www.eff.org/cafe
==========================
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@labs.gte.com sjj0@labs.gte.com stu.jacobs@verizon.com
==========================