1© 2002, Cisco Systems, Inc. All rights reserved.Protocol /IPSec

Securing Routing/Signaling Protocols w/ IPSec

David Ward

dward@cisco.com

222Protcol-IPSec

Overview

• Problem space

• Protocol/IPSec interactions

• Other efforts

• Future

NOTE: this is a non-charter presentation

333Protcol-IPSec

What are the problems?

• Protect the router as host - See rsec, ips, ipsec, msec, etc

• Protect the router infrastructure- peerid, passwords, socket, DOS

• Protect the protocol session data - encryption

• Protect the association of data to peer - See SBGP, SOBGP

• Create a secure VPN (IPSec tunnels) but, actually provide dynamic routing

444Protcol-IPSec

How to secure w/ IPSec?

• Protect the router - peerid, passwords, socket, DOS

• Protect the peering session data - encryption

• Summarize routing in a secure VPN - Touch/Knight

555Protcol-IPSec

Difference in Modes

New IPHeader

IPSec ESPHeader

Data

IP Header Data

Tunnel Mode

Original IPHeader

IPSec ESPHeader

Transport Mode

Original IPHeader

Data

Optional Encryption

Optional Encryption

Outer IP Header

Inner IP HeaderFrom: Paul Knight

Original Packet

666Protcol-IPSec

What is a Security Association (SA)?

All the information to establish secure (IPSec) communication

– Selection of the security mechanisms:ESP (Encapsulating Security Protocol) or AH

(Authentication Header)protectionCiphering algorithmHash function Choice of authentication method

– Authentication of the two parties– Choice of the ciphering and authentication keys

777Protcol-IPSec

What is the SAD?

Security Association Database:

All active security associations–Identifier :

•Outer destination IP address•Security Protocol•SPI – Security Parameter Index

–Parameters•Authentication algorithm and keys•Encryption algorithm and keys•Lifetime•Security Protocol Mode (tunnel or transport)•Anti-replay service•Link with an associated policy in the SPD

888Protcol-IPSec

What is the SPD?Security Policy Database:• Applies to every packet• For each policy entry, includes:

–Selectors•Destination IP Address•Source IP Address•Name•Transport Layer Protocol (protocol number)•Source and Destination Ports

–The policy :•Discard the packet, bypass or process IPSec•For IPSec Processing :

-Security Protocol and Mode-Enabled Services (anti-replay, authentication, encryption)-Algorithms (for authentication and/or encryption)

–Link to an active SA in the SAD (if it exists)

999Protcol-IPSec

What aspects of IPSec from ips work:

• Protocol security implementations MUST support transport mode ESP with NULL encryption and HMAC-SHA1 authentication.

• Transport mode MUST be supported: Between router as host

• IKE MAY be supported

• Tunnel mode MAY be supported when an IPSec Gateway is introduced inbetween routers

101010Protcol-IPSec

What aspects of IPSec (con’t 2)?

• Fragmentation issues solved w/ MTU discovery

• Connnections behind firewall or NAT like device covered w/ IPSec extensions

• Machine and User (if ever used) covered by IPSec

• Pre-shared keys for auto config (if ever used) covered by IPSec

• Brief description of Transport vs Tunnel

• Use transport mode when not running secure VPN overlay

111111Protcol-IPSec

What recommended transforms from ips?

• AES - CBC SHOULD be supported

• Solves key exhaustion issues

• 3DES MAY be supported - perhaps rekeying issues. Doubtful if any real problem.

• Deployment issue which transform to actually use

• Note that current protocol drafts don’t follow these recommendations

121212Protcol-IPSec

What is affected in Protocols?

• Not really a protocol extension

• Doesn’t affect OPEN, UPDATES, CAPABILITY NEGOTIATION, GRACEFUL RESTART, CLOSE, NOTIFICATION, etc.

• Have to clean up some protocol specification

• Not discussed in OSPF v2, needs cleanup OSPFv3

• Not discussed in RIP, needs cleanup in RIPng

• Not discussed in ISIS

• Not discussed in BGP

• RSVP - needs more work: draft-tschofenig-rsvp-sec-properties-00.txt

• LDP - not defined, md5 only (c n’ p from BGP), not a big deal to use IPSec

131313Protcol-IPSec

Summarize routing in secure VPNs (tunnel mode)

• What is the problem?

• The IPsec Security Associations have selectors that determine the traffic they allow. Like static routes.

• SP and SA Database lookups do the “routing”

• SA setup is orders of magnitude slower than routing change Dynamically changing SA due to routing updates doesn’t scale

141414Protcol-IPSec

Summarize routing in secure VPNs 0.2(tunnel mode)

• What is the solution?

(1) Use “wild card” in tunnel SAs (allow all traffic) OR

(2) Use encapsulation to make the traffic fit the “static route”, by setting destination address in the encapsulated traffic

• Either way you are “pushing” traffic into the VPN

• What are the relevant drafts?draft-touch-ipsec-vpn-04.txt, draft-wang-cevpn-routing-00.txt

draft-knight-ppvpn-ipsec-dynroute-01.txt

TunnelHeader

IPSec ESPHeader

DataOriginal IP

Header

Optional Encryption

TunnelHeader

DataOriginal IP

Header

151515Protcol-IPSec

What will using IPSec do to the network?

• Increase feeling of security in some cases improve security

• Add config and ops complexity

• Add to convergence time

• Increase use of system resources (cpu, memory)

• Give a generic solution to the auth/crypto problem that is already widely implemented

161616Protcol-IPSec

What to do next?• Really an ops/deployment doc and not protocol extension

• Certainly informational• Could be in IPS (security policy) could be in rpsec• Augment draft-bellovin-useipsec-00.txt (BGP as example)• Suggest Informational for RPSec• Generalized for routing/signaling protocols

– common auth, cipher, SA, bcast media handling, tunnel mode, etc

– right now we are all over the place

• UNCLEAR: Need decision from ADs, RAdirectorate, to agree to use IPsec for routing protocols

• Enables cleanup of current specs w/o massive thrash

• Enables a meta “ipsec for rpsec” doc instead of tracking individual specs: except where specifics are needed

171717Protcol-IPSec

What to do next?• Leave msec WG to do their thing

• Any protocol specific changes should be in proper WG (e.g. changes to IPsec for OSPFv3) but, generalized since the work doesn’t require protocol changes but, spec clarification.

• The auth algo, SA approach and ciphers are currently not following other specs. Virt links needs addressing.

• Not ready for primetime except BGP, LDP

IGPs have md5, V6 is IPSec

• Leave signaling for NSIS

• Fold in Joe Touch’s work or push it all into 2401bis?

Believe that routing stuff should be here including routing in secure VPNs

181818Protcol-IPSec

END - Remain calm at all times

• Actually can deploy ‘authenticated’ routing (for overlay VPNs and node to node) today

• In some cases encrypted

• We still have a lot of work to do if this is the direction that the RADs want us to go

• Is *immediate problem space* larger than EBGP?

• Implementation recommendations for DOS attacks due to IPSec deployments should be through another venue

• Enumerating the threats should be here

For open source info on routing in secure VPNs and IPsec/IKE implementations:

http://www.freeswan.org http://www.quintillion.com/fdis/moat/ipsec+routing/

This presentation represents the views

and opinions of the author and does not

necessarily reflect those of Cisco Systems.