1 / 18

Securing Routing/Signaling Protocols w/ IPSec

Securing Routing/Signaling Protocols w/ IPSec. David Ward dward@cisco.com. Overview. Problem space Protocol/IPSec interactions Other efforts Future NOTE: this is a non-charter presentation. What are the problems?. Protect the router as host - See rsec, ips, ipsec, msec, etc

zoltin
Télécharger la présentation

Securing Routing/Signaling Protocols w/ IPSec

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Securing Routing/Signaling Protocols w/ IPSec David Ward dward@cisco.com

  2. Overview • Problem space • Protocol/IPSec interactions • Other efforts • Future NOTE: this is a non-charter presentation

  3. 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

  4. 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

  5. Optional Encryption Optional Encryption Outer IP Header Inner IP Header Difference in Modes Original Packet Transport Mode IP Header Data Original IP Header IPSec ESP Header Data Tunnel Mode New IP Header IPSec ESP Header Original IP Header Data From: Paul Knight

  6. 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)protection Ciphering algorithm Hash function Choice of authentication method • Authentication of the two parties • Choice of the ciphering and authentication keys

  7. 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

  8. 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)

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. Optional Encryption 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 Tunnel Header Original IP Header Data Tunnel Header IPSec ESP Header Original IP Header Data

  15. 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

  16. 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

  17. 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

  18. 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.

More Related