Slide 1

Secure IGMP/MLDdraft-atwood-pim-sigmpdraft-atwood-mboned-mrac-reqdraft-atwood-mboned-mrac-archJ. William AtwoodBing LiConcordia University, MontrealIETF88-PIM1OverviewExploring the area of Receiver Access Control for IP MulticastSubtitle: Making money using IP MulticastCovers some of the same concerns as those of the well-managed multicast work that was presented in MBONED three years agomuch smaller scope of interestMBONED: application level draftsPIM: network level drafts2013-11-08IETF 88-PIM2Two AssumptionsThe End User (EU) acquires a ticket from a Merchant (or anyone else) containing:Session DescriptorSecure End User authenticationPossibly, an encryption key for the data streamThe Network Representative has information on how to validate a ticket or assess the authorization of the EU or EU DeviceThis makes the discussion today independent of the business model in use by the NSP and/or CPIt restricts the scope of the work

2013-11-08IETF 88-PIM33Two levels of interactionApplication LevelEU presents the ticketGoal: Join the groupNetwork LevelEnd User Device issues IGMP/MLD

To ensure that only legitimate subscribers get accessMUST be secure at Application LevelMUST be secure at Network Level2013-11-08IETF 88-PIM4Two ApproachesSolution 1Carry the ticket in an extended network-level join exchangeThe security of the two levels is implied by the fact that they are carried in a single level of message exchanges, which are securedSolution 2Provide separate secure application level join and secure network level join functions, along with a method for explicitly coordinating them2013-11-08IETF 88-PIM5Extending IGMPLong history of attempts to extend IGMPAll of them abandonedAll were restricted solutionsBased on a particular version of IGMP, -OR-Proposed a limited set of authorization methodsList of citations in the draftNone of these attempts considered accounting specifically2013-11-08IETF 88-PIM6Securing IGMP/MLDOne IRTF Internet Draft on securing IGMPOnce a device established a secure relationship with its router, it was allowed to send a join for any group.RFC 3376 suggests using AH to secure IGMP packetsRFC 3810 is silent on the issue of securing MLD packetsNone of these attempts considered accounting specificallyNo need to deploy the solution if accounting is unnecessary!2013-11-08IETF 88-PIM7ApproachWe choose Solution 2Reasons are in draft-atwood-mboned-mrac-reqThe Application-level requirements and the Interaction requirements in mrac-req are met in such a way that the End User and the NSP Representative will share a keyThis key can be used to derive keys for protecting MLD/IGMPA set of Network-level requirements remains2013-11-08IETF 88-PIM8RequirementsNetwork level constraints (for secure IGMP/MLD)Maximum Compatibility with MLD and IGMPGroup Membership and Access ControlMinimal Modification to MLD/IGMPMultiple Network Level Joins for End User DeviceNSP Representative Differentiates Multiple JoinsNetwork Level Interaction must be Secured

2013-11-08IETF 88-PIM9Open vs Secure GroupsOpen GroupNo access controlsOperations will follow standard IP multicast rules (3376 or 3810)Secured GroupAccess controls to prevent an unauthorized EU from accessing the groupAdditional operations are neededIGMP/MLD exchanges are protected with IPsec, using the derived keys2013-11-08IETF 88-PIM10Unsecure Query2013-11-08IETF 88-PIM11QNQEU1EU2EU3GQ V2, V3

224.0.0.1No groupQNQEU1EU2EU3GSQ V2, V3GSSQ V3

G_IPSingle groupSourceDestination11Secure Query2013-11-08IETF 88-PIM12QNQEU1EU2EU3GSQ V2, V3GSSQ V3Secure

G_IPSingle group12IGMP v2/v3 QueryThe GQ is an open solicitation, for all groups, and so cannot be secured with information that is specific to one group. So, it has no secure form.The GSQ (v2 and v3) and GSSQ (v3 only) are specific to a group, and so can be secured with parameters that are specific to that group. No change is necessary to the packet format; we only need to protect the packet with IPsec.2013-11-08IETF 88-PIM13Unsecure Report2013-11-08IETF 88-PIM14QNQEU1EU2EU3R V2

UnsecureSuppressionG_IPSingle groupQNQEU1EU2EU3R V3

UnsecureNO suppression224.0.0.22Multiple groups14IGMP v2/v3 ReportThe details of the v2 report and the v3 report are quite different, because different design decisions were made on how to minimize traffic:In v2, a Report contains only information about one group, but identical reports from other hosts should be suppressed.In v3, multiple groups may be contained in a single Report, which is sent to a common address (224.0.0.22)

2013-11-08IETF 88-PIM15Secure IGMP v2/v3 ReportSince the cryptographic protection must of necessity be specific to a group,We cannot use address 224.0.0.22We cannot have multiple groups in a Report messageWe are interested in minimum change to IGMPOur solution requires no change to the packet formatWe are interested in maximum compatibilityOur solution does not change the semantics of IGMP for open groups2013-11-08IETF 88-PIM16Secure Report2013-11-08IETF 88-PIM17QNQEU1EU2EU3R V2

SecureNO suppressionG_IPSingle groupQNQEU1EU2EU3R V3

SecureNO suppressionG_IPSingle group17Multicast Security Associ-ations for Secure IGMPMany distinct Multicast Security Associations are required on each network segment:One with Q as the sender, and NQ plus the admitted members as receiversOne for each legitimate participant EU, with the EU as the sender, and NQ plus Q as the receiversAll are uni-directional, as defined in RFC5374

2013-11-08IETF 88-PIM18Three external problemsThree problems are solved in a different document:Determining the keys for these MSAsDetermining the Security Parameter Index to useDistributing the keys and the SPIs to the participants who need them

2013-11-08IETF 88-PIM19ResultsSecure Authentication of IGMPAssuming that the keys are derived from the upper-level exchanges, the IGMP authentication and authorization is tied to the ticket of the End UserMinimal modification of IGMP semantics, and no modification of IGMP packet formatCompatible with all currently deployed versions of IGMP2013-11-08IETF 88-PIM20DocumentsIssuedMRAC Requirementsdraft-atwood-mboned-mrac-reqMRAC Architecturedraft-atwood-mboned-mrac-archSecure IGMPdraft-atwood-pim-sigmpTo ComeUsing PANA+EAP to achieve the MRACSecure MLDGSAM (coordination of Secure IGMP end points)2013-11-08IETF 88-PIM2121AcknowlegmentSalekul Islam contributed significantly to mrac-req and mrac-arch2013-11-08IETF 88-PIM22Next StepsRequest for feedback (on the list or elsewhere)

Eventual adoption of all three -pim documents as WG documents2013-11-08IETF 88-PIM23Thank You!2013-11-08IETF 88-PIM24

Questions?