Rserpool security
1 / 14

Rserpool Security - PowerPoint PPT Presentation

  • Uploaded on

Rserpool Security. Maureen Stillman July 14, 2003 [email protected] 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)

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Rserpool Security' - bracha

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Rserpool security

Rserpool Security

Maureen Stillman

July 14, 2003

[email protected]

Design team objectives
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

Pe and enrp security
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

Pu authenticates enrp server
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

Threats to consider
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


  • 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

Security architecture
Security Architecture



authentication, integrity

authentication, integrity

Mutual authentication, integrity





Mutual authentication, integrity

Enrp mixed security database
ENRP mixed security database

PE A pool “foo”


PE B pool “foo”

PE C pool “foo”

PE D pool “foo”

ENRP foo Database

PE A,C – secure

PE B, D – not secure

Mixed data base issues
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

Tls ports 1 port or 2 ports 2 port solution
TLS ports – 1 port or 2 ports?2 port solution

IANA assigns two ports for ENRP




Register with ENRP using TLS

TLS ports – 1 port or 2 ports?1 port solution

IANA assigns one port only




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

Advice received
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

Open issue control channel
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?

Next steps
Next steps

  • Are we there yet?

    • Are there other open issues?

  • Join the security design team to help