IPsec Deployments (Paul Wouters): September 6, 2017 11:12:49 AM from Kathleen Moriarty to everyone: From a little research, I thought some implementations fixed their NAT issues with transport mode, so the issues were known and could be fixed, but the motivation hasn't been there yet September 6, 2017 11:13:07 AM from Kathleen Moriarty to everyone: since it's not well deployed September 6, 2017 11:13:37 AM from Michael RIchardson to everyone: With effort, you can make transport mode work through NATs, but it requires significant in-kernel support to add additional keys to your socket structure. September 6, 2017 11:14:08 AM from Kathleen Moriarty to everyone: OK, so possible and may be desirable for this described usage and could increase it's deployment September 6, 2017 11:14:08 AM from Michael RIchardson to everyone: by significant, I mean, invasive. Easy if you own all the network stack, hard if you are trying to patch something in to someone else's stack. September 6, 2017 11:19:23 AM from Kathleen Moriarty to everyone: Yes and NAT is an implementation issue at this point if I understand correctly, so how do we motivate to get them fixed? September 6, 2017 11:19:33 AM from Kathleen Moriarty to everyone: I think NAT will matter in some data centers September 6, 2017 11:19:40 AM from Michael RIchardson to everyone: It's not a protocol issue, it's an implementation issue. September 6, 2017 11:20:03 AM from Kathleen Moriarty to everyone: Yep, Michael, we agree - how do we get that fixed? September 6, 2017 11:20:11 AM from Kathleen Moriarty to everyone: motivation wise September 6, 2017 11:20:21 AM from Michael RIchardson to everyone: throw money at Redhat. September 6, 2017 11:20:38 AM from Paul Wouters to everyone: use gateways site-to-site between data centers September 6, 2017 11:20:53 AM from Paul Wouters to everyone: then from client point of view, there is no NAT, and you can us etransport mode September 6, 2017 11:20:54 AM from Michael RIchardson to everyone: deploy IPv6 in the data center. September 6, 2017 11:21:06 AM from Paul Wouters to everyone: or that :) September 6, 2017 11:21:17 AM from Kathleen Moriarty to everyone: I think those that want to use it withing their data center would find transport mode more attractive to be able to monitor at least the 2-tuple September 6, 2017 11:22:11 AM from Kathleen Moriarty to everyone: I would think between many data centers, site-to-site is already in place ------------------ Scope of draft-abad (Gabriel/Rafa): September 6, 2017 11:22:47 AM from Tero Kivinen to everyone: If they use sdn then they can store all keys to and decrypt and monitor everything... September 6, 2017 11:26:04 AM from Kathleen Moriarty to everyone: Tero, that sounds scary. Group keying sounds better, but I don't know th details of how they would use the SND controlle September 6, 2017 11:26:06 AM from Kathleen Moriarty to everyone: r September 6, 2017 11:26:50 AM from Kathleen Moriarty to everyone: ANd the data center folks on this call (as far as I am aware) are just interested in automating deployment. The ones with a monitoring requirement may be a separate group September 6, 2017 11:27:05 AM from Tero Kivinen to everyone: Use case 2 is exactly that... all keys are stored and generated by security controller September 6, 2017 11:27:38 AM from Alejandro Perez to everyone: Note that keys are not stored, they might but that would be a bad practice. THey are genereated, distributed and forgotten September 6, 2017 11:28:12 AM from Valery Smyslov to everyone: But you still need to store SAD of all the NSF, right? September 6, 2017 11:28:29 AM from Tero Kivinen to everyone: They will be even if you say must not, as ha and fast recovery requires it... September 6, 2017 11:28:29 AM from Alejandro Perez to everyone: no, you don't. SAD is only stored on the NSFs September 6, 2017 11:29:16 AM from Valery Smyslov to everyone: OK, then you'll probably have hard time synchronizing SAs in case of any unpredictable event (NSF reboot) September 6, 2017 11:29:16 AM from Alejandro Perez to everyone: If a NSF falls, the Controller is notified and new SAs is estabalished September 6, 2017 11:29:34 AM from Valery Smyslov to everyone: Note, that SAs must not only be created, they must be deleted. September 6, 2017 11:29:44 AM from Alejandro Perez to everyone: SHould not be worse than trying to establish the IKE SAs again September 6, 2017 11:30:02 AM from Alejandro Perez to everyone: I agree September 6, 2017 11:30:08 AM from Valery Smyslov to everyone: IKE takes care of detecting and deleting erroneous SAs September 6, 2017 11:30:32 AM from Valery Smyslov to everyone: Now it is SDN controller's task September 6, 2017 11:30:48 AM from Kathleen Moriarty to everyone: Thanks, Tero. September 6, 2017 11:30:57 AM from Valery Smyslov to everyone: So it must have a full picture of all active SAs September 6, 2017 11:31:18 AM from Alejandro Perez to everyone: That's right. Basically a SDN controller has a full picture of the network it controlls September 6, 2017 11:31:55 AM from daniel to everyone: just connected. September 6, 2017 11:32:06 AM from daniel to everyone: my mic is muted September 6, 2017 11:32:26 AM from Alejandro Perez to everyone: Yes September 6, 2017 11:32:35 AM from Valery Smyslov to everyone: So either it stores a list of all SAs (probably w/o keys) or must dynamically collect this information from NSFs, right? September 6, 2017 11:32:56 AM from daniel to everyone: apology for being late. September 6, 2017 11:33:01 AM from Paul Wouters to everyone: i hear nothing ? September 6, 2017 11:33:07 AM from Valery Smyslov to everyone: Me too September 6, 2017 11:33:34 AM from daniel to everyone: i can hear tero and yoav. September 6, 2017 11:33:49 AM from Gabriel Lopez (UMU) to everyone: It can collect this from the NSF September 6, 2017 11:34:08 AM from Valery Smyslov to everyone: Note, that this list can be quite dynamic. September 6, 2017 11:34:40 AM from Valery Smyslov to everyone: It is really not a control plane, it is somewhere in between data plane and control plane. September 6, 2017 11:35:16 AM from Valery Smyslov to everyone: And you can pun quite a high additional load on SDN to manage SAs. September 6, 2017 11:35:28 AM from Alejandro Perez to everyone: The controller does not sends any data, why do you think it is in the data plane? September 6, 2017 11:35:33 AM from Valery Smyslov to everyone: Won't it be a scalability problem here? September 6, 2017 11:36:14 AM from Valery Smyslov to everyone: I said it is in betweed data and control plane, because this information is not static and can change pretty quickly September 6, 2017 11:36:46 AM from Valery Smyslov to everyone: For some high speed network you must create new IPsec SA every couple of minutes. September 6, 2017 11:38:06 AM from Alejandro Perez to everyone: But the process of creating a SA is quite simplified. Don¡t even need a DH exchange. A good RNG is enough September 6, 2017 11:38:10 AM from Paul Wouters to everyone: and have more then one betwen two endpoints while rolling to new key September 6, 2017 11:38:21 AM from Alejandro Perez to everyone: let's discuss this after the presentation September 6, 2017 11:39:30 AM from Fernando (CUD) to everyone: normal IKE requires peer communication, case 2 is proposing to perform this communication with the controller instead with the other peer September 6, 2017 11:45:48 AM from Michael RIchardson to everyone: what would a FIPS-140 evaluation conclude? September 6, 2017 11:56:42 AM from Alejandro Perez to everyone: The point is: the kernel does not know whether IKE or NETCONF is configuring the IPsec stack September 6, 2017 11:56:46 AM from Alejandro Perez to everyone: it does not matter, September 6, 2017 11:57:02 AM from Alejandro Perez to everyone: it does not care September 6, 2017 11:57:29 AM from Paul Wouters to everyone: it does, whoever asks to see ACQUIRe, EXPIRe msgs etc. September 6, 2017 11:58:01 AM from Michael RIchardson to everyone: this has been fun, I have another phone call now.... I think the world would be better if the SDN controller would push the simplest configuration and authorization (really big PSK if you like) to the endpoints. September 6, 2017 11:58:08 AM from Tero Kivinen to everyone: Not really true. Usually kernel and ike are quite tightly integrated, if you update one you need to update other too. September 6, 2017 11:58:22 AM from Alejandro Perez to everyone: Right, but it does not know it **is*** IKE September 6, 2017 11:58:24 AM from Michael RIchardson to everyone: the data center/VM key stealing by the VM host issues are REAL, September 6, 2017 12:01:01 PM from Paul Wouters to everyone: It's a good example September 6, 2017 12:03:50 PM from Alejandro Perez to everyone: RFC 7296: To rekey a Child SA within an existing IKE SA, create a new, equivalent SA (see Section 2.17 below), and when the new one is established, delete the old one. Itis not said that you have to wait until there is actual traffic September 6, 2017 12:09:06 PM from Paul Wouters to everyone: The core question is: at what point are you just creating a super-ike daemon on a central node. September 6, 2017 12:09:22 PM from Paul Wouters to everyone: that uses PFKEY-over-TLS September 6, 2017 12:10:54 PM from Fernando (CUD) to everyone: not a super-ike daemon because the SDN controller is creating keying material that distributes to NFVs September 6, 2017 12:10:54 PM from Paul Wouters to everyone: distribute connecton configs through the controller, and let the nodes run IKE September 6, 2017 12:11:01 PM from Fernando (CUD) to everyone: there is no IKE negotiation September 6, 2017 12:11:43 PM from Paul Wouters to everyone: you will rebuild some of it. like when there is a sha2_256 truncation bug in the kernel you have to work around September 6, 2017 12:11:52 PM from Fernando (CUD) to everyone: in case 2 NFVs are not running IKE September 6, 2017 12:11:54 PM from Paul Wouters to everyone: you will only not run DH :) September 6, 2017 12:14:11 PM from I2NSF Working Group to everyone: If it is technical feasible, but have risks, can we document the risks associated with the method in the draft? September 6, 2017 12:14:14 PM from Alejandro Perez to everyone: please. mute September 6, 2017 12:15:16 PM from Valery Smyslov to everyone: It has risks and is more complicated. So my question - what advantages case 2 has? September 6, 2017 12:16:58 PM from Paul Wouters to everyone: it does not have to be a central problem. if you have PFS via IKE September 6, 2017 12:17:37 PM from Paul Wouters to everyone: encryption keys and authentication keys do not need to be in the same egg basket September 6, 2017 12:20:03 PM from Henk Birkholz to everyone: Paul +1, there are pro&con to have specific & multi-purpose keys September 6, 2017 12:22:19 PM from Henk Birkholz to everyone: evidence relay via mitm is an attack vector, though, if keys are not entangled/associated somehow. September 6, 2017 12:28:15 PM from David Waltermire to everyone: Thanks!