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

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