[IPsec] IPsecME 105 Montreal preliminary minutes

Tero Kivinen <kivinen@iki.fi> Tue, 23 July 2019 21:38 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6B11203C2 for <ipsec@ietfa.amsl.com>; Tue, 23 Jul 2019 14:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.419
X-Spam-Level:
X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsb4cHr0ehIG for <ipsec@ietfa.amsl.com>; Tue, 23 Jul 2019 14:38:26 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA1B1202C5 for <ipsec@ietf.org>; Tue, 23 Jul 2019 14:38:25 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x6NLcMZB024426 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <ipsec@ietf.org>; Wed, 24 Jul 2019 00:38:22 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x6NLcLpv019861; Wed, 24 Jul 2019 00:38:21 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <23863.32333.879285.318503@fireball.acr.fi>
Date: Wed, 24 Jul 2019 00:38:21 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: ipsec@ietf.org
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 3 min
X-Total-Time: 2 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/F3cTaDu0tRU4rSpLJ48r1rFLZPw>
Subject: [IPsec] IPsecME 105 Montreal preliminary minutes
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2019 21:38:29 -0000

Here is preliminary minutes, if you have any comments, additions etc
to them, send them to chairs. Thanks to mcr to taking the minutes.

----------------------------------------------------------------------
# IPsecME WG
## IETF 105, Montreal

 * Date: 2019-07-23
 * Time: 15:20-16:50 (90 min)
 * Room: Sainte-Catherine

 * Chair: Tero Kivinen 
 * Chair: David Waltermire 

---
## Agenda
### Adminstrivia (5 min)

 * Agenda bashing, Logistics -- Chairs (5 min)

1) Paul asks about Graveyard draft, Chairs mention that authors need
   to push, chairs won't pull.

    Paul says that it is ready for WG Adoption Call.


### Draft status -- Chairs (10 min)

 * draft-ietf-ipsecme-implicit-iv
   - Implicit IV for Counter-based Ciphers in Encapsulating Security
     Payload (ESP) 

    Already in publication requested


 * draft-ietf-ipsecme-ipv6-ipv4-codes
   - IKEv2 Notification Status Types for IPv4/IPv6 Coexistence

    WG LC will be issued shortly


 * draft-ietf-ipsecme-qr-ikev2
   - Postquantum Preshared Keys for IKEv2 

    Already in publication requested state   

    Apple is shipping Postquantum in iOS 13
   

### Other issues

--- call for experts for independent review of candidate/nominated
    specifications for PAKE for CFRG. 
    Valery, framework for PAKE is RFC6467, integration for IKEv2 PAKE.
    Experimental RFC.  
    
    

### Work Items (25 min)

 * draft-ietf-ipsecme-ikev2-intermediate -- Valery Smyslov (5 min)
   - Intermediate Exchange in the IKEv2 Protocol
   
   INTERMEDIATE->IKE_INTERMEDIATE.
   Thinks this is the last rename.
   It can not be resumed.
   How the IKE_INTERMEDIATE exchange is included in the AUTH has changed again.

       authenticated as if it were sent unfragmented

    peers may disagree on length field in the headers, e.g. by padding
    differences. 

       -> remove the length fields.


    Should be ready for WG LC soon


 * draft-ietf-ipsecme-labeled-ipsec -- Paul Wouters (5 min)
   - Labeled IPsec Traffic Selector support for IKEv2
   
   went back to previous version of the format.
   opaque blob with a >0 length

   Valery pointed out that the text restricts ability for a responder to
   select more than one TSi (if proposed). Paul replies that this was
   unintentional, and will be removed.

   Also should be ready for WG LC soon


 * draft-yeung-g-ikev2 -- Valery Smyslov (15 min)
   - Group Key Management using IKEv2

   Is the GSA_REKEY signed (assymetrically) by Initiator?
   YES, there is this [AUTH] payload (optional, could be symmetric key
   only). 

   Large step forward since IETF99, more implementations interoperated
   before, but significant changes which need to be retested.

   MCR asked if there was really the multicast expertise of
   implementors in the WG. Tobias Heider from U of Munich answers in
   Jabber.

   Should be ready for WG Adoption call.


### Other presentations (35 min)

  * draft-tjhai-ipsecme-hybrid-qske-ikev2 -- Valery Smyslov (10 min)
    - Framework to Integrate Post-quantum Key Exchanges into Internet
      Key Exchange Protocol Version 2 (IKEv2)  

      Do we need fresh nonces in every IKE_INTERMEDIATE?
      
      Scott Fluhrer says that the nonces are for nonces, and we have
      already proved things by completing the first AUTH.

      Tero: Why are you using INFORMATIONAL for additional
      information?
      
      Valery: Because we want to have the same properties as the
      first, and INFORMATIONAL is wildcard.
      
      Paul suggests using new exchange called "SA_INTERMEDIATE"

      Tobias (jabber): +1 on Paul.

      MCR: asks about how the state machine can be verified without
      having some QSKE to chain to?

      Scott: Proposed they could use group 18, which is already big.

      Tero: There has also been some interest to add 12k and 16k DH
      keys, they would be even larger.
      
      Tobias Heider: mic: We at LMU Munich are actually working on a
      formal verification model to make sure the state machine is working

      Should be ready for WG Adoptation call.

  * draft-hopps-ipsecme-iptfs -- Christian Hopps (10 min)
    - IP Traffic Flow Security 
    
    Added a don't fragment bit.
    moved congestion control from out-of-band to in-band.
    
    David Black: Transport experts were asked, and it looks like they
    got it right.
    
    Valery: the purpose is to fill as much data as possible?
    
    No: the purpose is to hide the data size.
    
    Valery: for a fixed packet size, you want to put as many data as
    possible? Did you consider to reduce the size of the reserved
    fields?

    Yes, considered ways to eliminate the header all-together. The
    implementations will either set to the largest MTU, or will do
    Path MTU in general.... but alignment is good.

    Paul: you are using a traffic selector to request this?
    
    No, it's a transform selector. 

    Yoav: not only is this supposed to do, but IKEv2 was supposed to
    do this properly from the start.

    Tero: the measurement, was it done with real traffic, or ??
    
    Chris: it was done with I-Mix traffic distribution?
    
    Tero: asks about latency?  you can't wait for long time because of
    TCP ACKs
    
    Chris: yes, there is a latency problem, and so there is an
    challenge. 

    This is not part of our charter, we need to recharter to include
    this. There seems to be enough 

    interest for this work, so chairs will propose new charter item to ADs.


  * draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt -- Wei Pan/Sandeep
    Kampati (15 min) 
    - IKEv2 Optional SA&TS Payloads in Child Exchange 
   
   MCR: hypothesis that rekey situation 3 is not interesting, that
   most will just kill (IKE) SA and restart.
   
   Scott reports that his products will apply the new policy to the
   CHILD SA without killing IKE, i.e., using rekey.

   Bharath Meduri: For ACL Change Kill all and create new. but for
   crypto just allow after reky
   
   Paul points out that we should never have send the TSx on rekey, so
   that nobody could change them by mistake.
   
   Valery: suggest that it is not useful for IKE, and that maybe just
   do this for Traffic Selectors, and not SA properties.
   
   Tero: if you are rekeying that you are using the same thing, then
   this makes sense, just rekey, i.e., send REKEY_SA notify, and
   include new SPI there, and leave the SA and TS payloads out. Just
   do not bother rekeying the IKE SA, so what's the point of
   optimizing this. If you do so much that the algorithms or TS are
   changing, then it isn't a REKEY.
   
   Tero says that is in the charter, as it fits into compressing
   IKEv2.
   
   Tero suggests that there is enough interest.
   
   Document will get a WG Adoption Call.

Other business:
    
    Paul:  no-one from NIST is talking about new document.
    Revision-1 guide to deploying IPsec VPNs.
    

-- 
kivinen@iki.fi