1 / 14

Rserpool Security

This document aims to secure the Rserpool infrastructure by implementing TLS or IPsec security, supporting client to ENRP server authentication, and preventing threats such as rogue ENRP servers and unauthorized PE registrations. It also discusses issues related to data integrity and mixed ENRP databases.

naumann
Download Presentation

Rserpool Security

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. Rserpool Security Maureen Stillman July 14, 2003 maureen.stillman@nokia.com

  2. Design Team objectives • Revisit i-d draft-ietf-rserpool-threats-00.txt • Add directives from Transport Area Directors • Secure Rserpool infrastructure • does not include application (PU-PE data) • Support client (PU) to ENRP server authentication • PU authenticates ENRP server to prevent rogue ENRP servers

  3. PE and ENRP security • Mandatory to implement TLS OR IPsec security • Choice is design decision left to the designers and network architects • Open issue • Since the last IETF design team has only talked about TLS – do we want to mandate this only and not discuss IPsec? • Using IPsec • Must implement draft-ietf-ipsec-sctp-04 • Using TLS • MUST support TLS with SCTP as described in RFC 3436 or TLS over TCP as described in RFC 2246

  4. PU Authenticates ENRP server • Consensus reached by the security design team • TLS would be used by the PU to authenticate the ENRP server (mandatory to implement) • Other methods of authentication are optional • TLS was deemed mandatory to implement for reasons of interoperability

  5. Threats to consider • What are the threats? • Rouge ENRP servers • Rouge registrations from PEs or unauthorized PEs • PE thinks it has registered with a “good” ENRP server, but it is really a rouge • Corrupted data • Sent from the ENRP server to the PU • Sent from the PE to the ENRP server • PU-PE authentication addresses only #1

  6. Issues • What I really want to know is that the addresses served up to the PU are “trusted” • Want to know that all the PEs have registered with a “trusted” ENRP server • Therefore, the real threat is the one of bogus addresses for PEs or no addresses for the PEs • Do we need data integrity as well? (yes) • What about a “mixed” ENRP database – some entries trusted, some not

  7. Security Architecture PU PU authentication, integrity authentication, integrity Mutual authentication, integrity ENRP Server PE PE Mutual authentication, integrity

  8. ENRP mixed security database PE A pool “foo” ENRP PE B pool “foo” PE C pool “foo” PE D pool “foo” ENRP foo Database PE A,C – secure PE B, D – not secure

  9. Mixed data base issues • Need to mark PE registrations – some have used security to register others not • When a PU requests a list, does it get the mixed list or one or the other? • Makes implementation more complex • Conclusion – mixed database not allowed; either all secure or all not secured

  10. TLS ports – 1 port or 2 ports?2 port solution IANA assigns two ports for ENRP PE ENRP PE Register with ENRP using TLS

  11. TLS ports – 1 port or 2 ports?1 port solution IANA assigns one port only PE ENRP PE First send unsecured message with upgrade to TLS request; MITM can refuse upgrade; Fix: Protocol change to ASAP to request upgrade; can’t be rejected by ENRP

  12. Advice received • We have gotten advice from Jon Peterson and Eric Rescorla • Both endorse the 2 port and one port solutions • We have asked IANA for two ports

  13. Open issue – control channel • Two options • Data channel only • Control and data -- We have decided to multiplex the data and control channel • When the data channel is secured, the control channel is as well due to the mux • If data is not secured, neither is the control • Is this solution OK?

  14. Next steps • Are we there yet? • Are there other open issues? • Join the security design team to help • E-mail maureen.stillman@nokia.com

More Related