Sept 6 Interim Chat Record
slides-interim-2017-i2nsf-01-sessa-sept-6-interim-chat-record-00

Meeting Slides Interface to Network Security Functions (i2nsf) WG
Title Sept 6 Interim Chat Record
State Active
Other versions plain text
Last updated 2017-09-08

Meeting Slides
slides-interim-2017-i2nsf-01-sessa-sept-6-interim-chat-record

   ÿþ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!