[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@xxxxxxxxxxxx sjj0@xxxxxxxxxxxx  stu.jacobs@xxxxxxxxxxx
> ==========================
>

 --
Jan Vilhuber                                            vilhuber@xxxxxxxxx
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@xxxxxxxxxxxx sjj0@xxxxxxxxxxxx  stu.jacobs@xxxxxxxxxxx
==========================