Minutes IETF106: ipsecme
minutes-106-ipsecme-00

IPsecME WG - IETF 106, Singapore
Date: 2019-11-21 15:50-17:20 (90 min)
Room: Olivia

Chairs: Tero Kivinen <kivinen@iki.fi>, David Waltermire <david.waltermire@nist.gov>
Scribe: Sean Turner

Agenda
======

  * Adminstrivia (5 min)
    * Agenda bashing, Logistics -- Chairs (5 min)
  * Draft status -- Chairs (10 min)
  * Work Items (25 min)
    * draft-tjhai-ipsecme-hybrid-qske-ikev2 Interop
    * draft-hopps-ipsecme-ipft
    * draft-ietf-ipsecme-labeled-ipsec
  * Other presentations (40 min)
    * draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt
    * draft-pwouters-ikev1-ipsec-graveyard
    * draft-smyslov-ipsecme-ikev2-qr-alt
    * draft-mglt-ipsecme-multiple-child-sas

------------------------------------------------------------------------------

Adminstrivia
============
(chairs)
https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-chair-slides-02.pdf

No agenda bash

Draft status
============
(chairs)
https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-chair-slides-02.pdf

No comments.  See slide 5-6.


Work Items
==========


QSKE Hybrid Interop
===================
(Valery Smyslov)
draft-tjhai-ipsecme-hybrid-qske-ikev2
https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-hybrid-qske-for-ikev2-interoperability-testing-event-01

S Turner: Consider: publishing to
  	  https://ietf.org/how/runningcode/implementation-reports/
Jonathan Hammell: Did you test child rekey?
VS: No.
David Waltermire: Plans to do so?
VS: Yes once draft is adopted.  Needs more list discussion.
David Waltermire: Please post the feedback to the list,


IP Traffic Flow Security
========================
(Christian Hopps)
draft-hopps-ipsecme-ipft
https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-ip-traffic-flow-security-00

VS: You seem to leave out transport mode?  Any reason?
CH: We only tunnel.  We need to encsapsulte and shrink it and grow it.
VS: Do you see a need for transport mode?
CH: Transport Mode is the least secure because you give away souce and
    deestination.  You are gicing away so much already why bother. 
VS: You want to allocate an IP protocol number?  Is it only use on ?
    next protocol.  Do you need it? 
CH: It's the scope of how the next header field.  It's easier to get a
    new protocol number than redoing ESP registry. 
Ben Kaduk: IP # is kind of a big deal, the IESG give each other a
    	   heads-up when there's potential for allocating one.  My
	   second point is about the alignment question -- the general
	   sense I get from the IETF as a whole is that if we have to
	   be adding new protocol machinery for things like variable
	   length paddding then there's not much interest   in the
	   rest of the IETF. Just adding a byte of padding so our
	   fields are internally consistent is generally reasonable,
	   if we can spare the space. 
CH: We would probably align on 32.
Tero: For the protocol # since we only need it in inner esp trailer.
      We could just say there are multiple buckets inside.  The other
      option is to use WRAP ESP.  Third option is that since we
      negotiate in IKE we can say the final protocol is ignored becaue
      it has no meaning.  
Michael Richardson: If we use WRAP ESP that would be the protocol
		    number of the outer or the next header within ESP? 
Tero: I would put it as the outer.
Michael Richardon: When we do ESP ove UDP doesn't the outer say it's
		   ESP so we don't know the protocol. 
Tero: WRAP ESP does explain how to do it over UDP.
CH: We shouldn't be so freaked out about asking for an early allocation.
Michael Richardson: I am supportive of making use of WRAP ESP.
David Watermire: Tero please send some examples of how this might work.
Chair: There is some consensus in the room to invistigate options that
       would not require a new IP # assignment. Options should be
       explored first before requesting assignment. 


Labeled IPsec Traffic Selector support for IKEv2
================================================
(Paul Wouters)
draft-ietf-ipsecme-labeled-ipsec
https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-labeled-ipsec-00

VS: I think the second one is not really an option.  Traffic selectors
    are a logical or.  The third option is the most right from a formal
    point of view.  It will lead to an explosition of types.
Hu Jun: Don't like 3 one.  Notify is a new rype to a tunnel not the
   	child SA. 
PW: This would work for a child SA.
Michael Richardson: Consider two things: 1 how would an implementation
 		    that doesn't support it respond, 2 is it useful
		    for an endpoint will negotiate and end point that
		    doesn't have?
PW: It would be a failure - no tunnel would result.
Michael Richardson: Not sure it matters which choice you make then.
PW: Do that into account that I have a specific use, but other might
    want to support it. 
Michael Richardson: Unless these others complain just do you what you want.
Tero: Prefer option 3.
Ben Kaduk: Relaying Yoav from jabber: The notify payload seems better
    	   because nobody has ever defined new traffic selector
    	   types, but we have done notify types.  Implementations
    	   might choke on a new TS type  
Daniel Migualt: Where is the label going to be used.
Chair: Sounds like the 3rd option?
PW: In theory 3rd option is nice, but 1st option is practially better.
VS: It might be discussd on the list.
Tero: Notify is bad because you know have to do tear downs if you
      don't need it. 
SPT: I agree with Paul -- 3 is what you'd do if you were perfect
     world, but 1 is the practical option that we have to do.  We could
     hum for option 1 and confirm on the list. 
Tero: problem with option 1 is that it's not in any drafts.  Postpone
      hum until we have something in writing.
Michael Richardson: Just do humm for objection?
Chair: If you understand what we're asking for in Option 1.
[some hums, pretty quiet]
Chair: any concerns with option 1?
[one from jabber but none apparent in room]
Chair: Write up what option 1 would like and go from there.


Other presentations
===================


IKEv2 Optional SA&TS Payloads in Child Exchange
===============================================
(Wei Pan)
draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt
https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-ikev2-optional-sats-payloads-in-child-exchange-00


Paul Wouters: What i do not like is that initiator can send the notify, but
     	      the responder can reject it.  Because now I have a
     	      failed rekey.  Does you responder dynmically decide to
     	      do this or not? 
WP: We think that for some products we will give the confurations on
    the responder side and this will occur immediately. Some products
    may not do this immediately.  
Paul Wouters: So now what you're saying you negotiate what you are
     	      willing to do, buyt soimewhat in the middle don't do it.
Michael Richardson: Take the initial is AES-256, AES-128 but responder
     	      	    has only AES-128. They agree on AES-128. Now if
     	      	    responder policy changes to allow AES-256 (in
     	      	    addition to AES-128) then they can rekey and
     	      	    switch to AES-256.
PW: It's not allowed you have to do the exact same parameters.  You
    need to use the same parameters throughout. 
VS: I do not think this draft gives us enough optimization.  For child
    SA it is slightly different beause you need pull traffic selector
    and it can be quite long.  
WP: It is their aim and we implemented it.
Christian Hopps: Isn't it just possible that this is over engineered.
     	      	 Just tear the SA down so you can avoid the issues.  What
     	      	 you chances of screwing it up. 
Paul Wouters: For the Child SA it is really useful.
Tero: I don't like because it's just more options because it increases
      that chances of mistakes. 
Ben Kaduk (Yoav Nir): Why not just have one notification type? (since
     	      	      the context makes it clear which type of SA is
     	      	      being referred to).

Chair: There is some IPR.
Sean Turner: It says reasonable and non-discriminatory, with
     	     possibility for royalty-free. 
Tero: having to talk to IPR holder before implementing is annoying.
Ben Kaduk: Need to update/review charter before adopting.
Paul Wouters: We thought about the minor charter updates - this is
     	      minor extension WG and this is minor. 


Deprecation of IKEv1 and obsoleted algorithms
=============================================
(Paul Wouters)
draft-pwouters-ikev1-ipsec-graveyard
https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-ikev1-graveyard-01

Dan: It says IKEv1 MUST NOT be deployed.  Can't really say that.
Tero: We closed the registry anyway programatically.
Dan: Who did you tell?
Tero: We sent a liaison.
Ben Kaduk: We should send a liaison before we close them.
Dan: we're doing the same kind of thing in TLS.
Ben Kaduk: IESG will send it.
Sean Turner: Will send some text about historic.


An Alternative Approach for Postquantum Preshared Keys in IKEv2
===============================================================
(Valery Smyslov)
draft-smyslov-ipsecme-ikev2-qr-alt
https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-an-alternative-approach-for-postquantum-preshared-keys-in-ikev2-00

Daniel: This draft has been presented many times we should adopt it.
VS: This is the first time.
Tero: Who read it: 3.
WP: Easy to understand and should be done.
David Walertmine: Daniel and Paul volunteered to read the draft. 


Multiple SAs in one create child SA exchange
============================================
(Daniel Migault)
draft-mglt-ipsecme-multiple-child-sas
https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-draft-mglt-ipsecme-multiple-child-sa-00

Tero: I don't think we can do this with SPi nubmers.  We had this in
      IKEv1, but only one person implemented and nobody wanted it.
      Need use case before implementing 
Daniel: You can extend SPI as long as you like.  The use case is when
      	you have multiple cores. 
Michael Richardson: Replay counter impacts.
Ben Kaduk: All the Child SAs get the same traffic selectors.
Daniel Migualt: Yes.
VS: Remember there is an indiviation of # keying material because
    there is a counter so you can't interate on SP+ more than #. ... 
Daniel: ....
Paul Wouters: I also thought about this a while ago.  There are three
      	      use cases:
	      1) brigin up many Childs SAs with PFS for each one -
      	      	 Tero came up with a better solution,
 	      2) To do more processing on CPU - you can do this on
      	      	 demand when a new CPU comes online,
	      3) For QoS you can just bring them up on demand.  So
      	      	 this optimiztion is not really that I understand.
Daniel: What to exchange 24 cores.
Paul Wouters: At that point you got Gigs so why bother.


Open Discussion
===============