1 / 18

Securing PIM-SM Link-Local Messages

Securing PIM-SM Link-Local Messages. J.W. Atwood Salekul Islam Concordia University draft-ietf-pim-sm-linklocal-00. Motivation. Goal: To permit authenticating the router-to-router traffic in PIM-SM Router-to-router (link-local) messages are multicast to “ALL_PIM_ROUTERS” : Hello Join

seanna
Download Presentation

Securing PIM-SM Link-Local Messages

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 PIM-SM Link-Local Messages J.W. Atwood Salekul Islam Concordia University draft-ietf-pim-sm-linklocal-00

  2. Motivation • Goal: To permit authenticating the router-to-router traffic in PIM-SM • Router-to-router (link-local) messages are multicast to “ALL_PIM_ROUTERS” : • Hello • Join • Prune • No effort to secure user data (see RFC 3740) • No effort to secure unicast PIM messages

  3. Characteristics of message exchange • Each router multicasts on its interface(s) • Appears to be a multi-speaker (ASM) group • In fact is multiple single-speaker (SSM) groups using the same multicast address. • No explicit “join” or “leave” to the group “ALL_PIM_ROUTERS” • This makes manual configuration possible (but ugly)

  4. Authentication/Confidentiality • PIM-SM spec says use AH • OSPF v3 (RFC 4552) specifies using AH for authentication and ESP for confidentiality • One respondent said “if you need confidentiality, use ESP for both” • Is there an operational need for confidentiality? • If so, which combination of IPsec (AH, ESP, AH+ESP) do we recommend?

  5. Key Management • MSEC participant gave four reasons for automated key management • Speaker router crashes/reboots • Receiver router crashes/reboots • Key management hygiene (24 hour lifetime) • Group key compromise • Seems (to us) to be a strong motivation to develop automated key management

  6. Issues • Manual Key Management is MUST implement • Need to have this fall-back in case operator does not want GCKS overhead for his admin region • How about Automated Key Management? • MUST? • SHOULD? • MAY? • One respondent argued for MUST; we agree

  7. Number of SAs • Unique SA per outbound node (speaker) • Receiving router has (n+1) SAs • N = number of peers, not total number of routers in region • Addition of one router adds an SA to all other directly connected routers • Only feasible with automated key management • If automated key management is MUST, then this mode will be “MUST implement” as well • Else this mode will be “MAY implement”

  8. Number of SAs 2 • One outgoing SA, one incoming SA per region • Same SA for all routers • RECOMMENDED for manual keying configurations • MAY be used for automated keying configurations • Suffers from impersonation attacks • Not useful if anti-replay is implemented

  9. SA Lookup • Unicast • SPI, DestAddr, SecProtType (AH, ESP) • Multicast • SPI; may use DestAddr (or DestAddr+SourceAddr) • Do not use AH/ESP • Exchanges are really SSM at an ASM address • Global address for sender means that Source Address is sufficient to resolve SA

  10. Per-interface SAD? • PIM-SM says • Per-interface SAD may be useful • IPsec says • No (longer) need to support per-interface SAD • AH says • Use SPI + destination + source for SSM • Use SPI + destination for ASM • Since the groups are really SSM, can use source address

  11. Per-interface 2 • Source addresses are globally unique • No need to differentiate on a per-interface basis • One commenter said that packets can be sent with zero addresses (IPv4) or (non-unique) link-local addresses (IPv6). • We can find no instance where this is allowed in the PIM-SM spec. • If anyone has a specific case, we would like to have a pointer!

  12. Per-interface 3 • Our conclusion is that Per-interface is not required.

  13. Rekeying Rules • To be determined, once it is confirmed that the WG would like to see automated key management developed for PIM-SM

  14. Activating Anti-replay • PIM-SM says • Assume manual keying, but allow automatic • Anti-replay SHOULD be enabled • AH says • SHOULD NOT offer anti-replay when manually keyed

  15. Anti-replay 2 • IPsec says • Security Policy Database (SPD) cannot represent a creation policy for a multicast SA • Therefore, only manually-configured SAD entries are possible • Conclusion • Extend the SPD (happening in MSEC) • Define a negotiation protocol to use these extensions • Is there WG support for this?

  16. Anti-replay 3 • Implementing anti-replay at one router implies having an SA (with an associated sequence number) for each peer • Need to keep (n+1) SAs • Each differentiated using the Source Address of the peer

  17. Multicast address ALL_PIM_ROUTERS • Link-local messages go from one router to all its peer routers, using ALL_PIM_ROUTERS • This is an ASM group address • In fact, the communication is a collection of SSM groups • However, the IP Protocol ID field can be used to differentiate • Unsecure = 103, secure = 50 or 51 • Therefore, no need to introduce a new address

  18. Contact Information • PPT/PDF of these slides are at www.cse.concordia.ca/~bill/internet-drafts/IETF67-LinkLocal-00.ppt orIETF67-LinkLocal-00.pdf • Email addresses • bill@cse.concordia.ca • salek_is@cse.concordia.ca

More Related