Subject: [secdir] SecDir review of draft-ietf-pim-join-attributes-for-lisp-05

From: "Brian Weis (bew)" <[email-masked]>
Date: Fri, 21 Oct 2016 17:51:25 +0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

I consider this draft to be Ready.

When a LISP-enabled site has a multicast source emitting messages to other LISP-enabled sites, PIM is used to report that there are multicast receivers within those LISP-enabled sites. These PIM messages are encapsulated with LISP over the provider network (“RLOC address space”) to a LISP ITR at site containing the multicast source. This Internet-Draft adds an attribute to PIM that enables PIM at the LISP xTR in front of a multicast receiver to indicate how it would like to receive the multicast data packets. It may indicate that the LISP multicast data messages are to be sent as native multicast LISP encapsulated packets (replicated in the provider network) or as unicast LISP packets. When unicast packets are selected, another new attribute can indicate  exactly which unicast receiver RLOC to which the multicast messages should be addressed. Security considerations of the semantics for protecting the multicast data packets are outside the scope of this document.

These new attributes are all delivered in PIM messages, which are sent encapsulated in LISP, and if a user has chosen to protect the LISP traffic across the provider network for confidentiality or privacy reasons, and/or chosen to protect the PIM packets with an integrity method, then the new attributes will also be protected. The information in the attributes related only to delivery of the packets, and there are no particular privacy considerations. The current Security Considerations section seems adequate.

Brian

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 21 Oct 2016 11:03:53 -0700

> These new attributes are all delivered in PIM messages, which are sent encapsulated in LISP, and if a user has chosen to protect the LISP traffic across the provider network for confidentiality or…

Yes, using lisp-crypto. But do you think different keying should be used for data versus control traffic?

Dino

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Fri, 21 Oct 2016 21:19:35 +0000

Hi Dino,

> On Oct 21, 2016, at 11:03 AM, Dino Farinacci <[email-masked]> wrote:
> 

I don’t think they necessarily need to be keyed differently. I expect that the xTRs are trusted to are distribute both data and control traffic to the same peers.  But there are some considerations to using lisp-crypto for this:

(1)  Since lisp-crypto doesn’t actually authenticate the peer (i.e., it’s intent was for privacy of data) then there’s no guarantee that the PIM peer is authorized. If authorization of the peer is not needed, then no problem. But if you expected to restrict the flow of LISP encapsulated data then once should use an encryption method that includes authentication of the peer.

(2) If both flows are purely unicast then lisp-crypto can be used, but since lisp-crypto is Diffie-Hellam based only two xTRs will know the key. When LISP packets are sent as native multicast packets across the provider network there are likely multiple receivers, all of which need the same session keys as the sender. One would need to use something like GDOI (RFC 6407) to distribute a group key to the xTRs to protect the data traffic.

Brian

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 22 Oct 2016 11:17:59 -0700

> I don’t think they necessarily need to be keyed differently. I expect that the xTRs are trusted to are distribute both data and

Okay. 

> control traffic to the same peers.  But there are some considerations to using lisp-crypto for this:
> 
> (1)  Since lisp-crypto doesn’t actually authenticate the peer (i.e., it’s intent was for privacy of data) then there’s no guarantee

Well as you know the lisp-crypto cipher suites use AEAD so there is mechanism, we'd just need more detail here. 

> that the PIM peer is authorized. If authorization of the peer is not needed, then no problem. But if you expected to

Well we have to start out as an open system so any ETR is allowed to join an ITR for an (S,G). Having it authorized to do so can be done by the mapping system. If the mapping system doesn't return the RLOC of the ITR for any ETR, they can't join. 

> (2) If both flows are purely unicast then lisp-crypto can be used, but since lisp-crypto is Diffie-Hellam based only two xTRs will know the key. When LISP packets are sent as native multicast packets across the provider 

Right I was referring to the control plane where joins would normally be unicast. 

> network there are likely multiple receivers, all of which need the same session keys as the sender. One would need to use something like GDOI (RFC 6407) to distribute a group key to the xTRs to protect the data traffic.

Not trying to solve that. Right now if you want multicast to be encrypted, you do that with replicated unicast, where the ITR uses different keys and key-IDs for each packet being unicast encapsulated to each ETR. 

Dino