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

[Dino Farinacci <[e-mail]>]

> 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