IPsec ME minutes IETF 91
Minutes taken by Paul Wouters

PaulH: brief status report (see slides, new RFC's 7321, 7296, 7383, signature-auth in queue)

Yaov: Someone found a way to make TCP connections inside tunnels fail,
     but using PACKET_TOO_BIG messages to the gateway that make the tunnel
     MTU go below the minimum for the IP version by reducing the ESP PMTU
     down to the minimum.
Yoav: sector list[?] there is a paper?


Valery on NULL auth:

- intial contact clarified (must be ignored)
- early code point requested

- no formal security proof
- channel binding
 two peers can authenticate each other out of band if needed. not an issue

- more security considerations are needed

Paul Wouters offered help
PaulW: exposing ports can be desirable for some
Tero: can use transport mode to reveal those
Tero: waiting for this meeting for early code point
     id_null or empty id can be changed without much problems
     auth_none method won't change so that is safe too. if not speak up NOW
PaulH: any major change to be submitted? no. ok tero send to IANA.
PaulH: security proof is not required. Yaron backed down on requiring it.
Dan Harkins: been beaten on head for lack fo security proof. typically not required in ietf
            This follows usual path.
PaulH: mailing list said no channel binding
Brian Weis: Ok I wont ask for formal security proof
PaulW: there are places in code where we thought "this is fine becaus
      it is only authenticated". We need to revisit those decisions now.
Yaron: I am mostly worried about people assuming that one-sided auth is
      as good as TLS, which may not be true when investigated formally.

PaulH: WGLC soonish
PaulH: who else feels confident (2 more) (besides, Paul, Valery)
Yaron: for the record, I disagree with my esteemed co-chair. OK with code assignment, not yet OK with LC.
PaulH: chairs will discuss


Valery:  D. Migault and me published draft-clone-ike-sa
        Please look at this for adoption/rejection
PaulH: we'll ask for interest on the list


Yoav: Defending IKE Responders Against Denial of Service attacks" presentation
Yoav: anti-ddos slides
Michael Richardson: should we be changing our scope for this document due to null_auth?
Yoav: out of scope for now in the draft. We should think about it.
PaulH: we can ask that question later.
Yoav: for now we assume attacker cannot complete AUTH
Yoav: attacker receiving ike_init can cheaply sent nonsense AUTH, causing lots of work on responder
Yoav: even more complex, attacker send AUTH that decrypts OK, then fails
Yoav: basic defense, stateless cookies. does not stop attacks with return routability
Yoav: rate limiting of half-open based on v4 address or v6 range
Yoav: if half-open sa db is attacked, reduce retention time. usually 3-5 seconds seems ok value
Yoav: puzzles for attackers that can send IKE_AUTH.
Yoav: puzzle now based on proof-of-work in bitcoin blockchain (see slide)
Tero: known ip's to use puzzles to proof (eg known home workers ip)
Valery: different puzzles for different IPs? [could not understand much]
Valery: crypto agility missing
Yoav: we can require more digits, more zeroes, if sha2 would become weaker / easier to solve
Brian Wise: do we want a registry of puzzles and only do one now?
Brian Wise: you changed puzzle, but mechanism is still the same ?
Yoav: previous one was responder gave initiator most of the cookie. But it was patented,
     so switched to current system. is used in bitcoin, no one has sued there yet
Brain Wise: if client can't do puzzle there are out in the last scenario?
Yoav: yes, that's why you do this last. it will affect legitimate clients
PaulH: that's why the draft now statesm ore about DOS and not just puzzle
Rene Hummen: the puzzle offsets connection establishment. doesn't it just moves the [problem point]
Rene: you are just delaying the problem.
Yoav: No, we are reducing the rate of the botnet as a whole
Yaron: with a 5/sec rate limit, the puzzle is meaningless, because
      attackers are desktops and so the puzzle is worth 0.1 sec or less. I
      still support puzzles, because they mitigate a botnet that's attacking
      *multiple* uncoordinated gateways
PaulW: asking if draft says something about making it easier for reconnecting puzzle solvers
      to help them not empty their battery
Yoav: use the ticket RFC for that.
Ron van Meter: What is the effect on network load going to be? I think only a factor 2 or 3, so modest
Yoav: it reduces the number of packets the attackers can really (usefully?) send.

PaulH: few minutes left

Rod van Meter: QKD draft revived from a couple of years ago. Got a lot of responses on the
              mailing list. we're planning this to the independant stream. we appreciate
              the feedback we got so far.

PaulH: we are not asking for WG daoption. Independant submission is outside the ietf. only
      thing that will happen is that they will ask IESG if this an endrun around something.
      It is okay to discuss on mailing list.

Rod: couple of Q's left, feedback sooner rather than later wouldbe good.

Tero: I'd rather have it as individual draft. it is still modification to IKE, would still
     like IETF to look at it.
PaulH: nothing prevents us to pull it in later, especially if we have concerns
Kathleen Moriarty: (our AD): was there a call for adoption?
PaulH: eons ago, no interest
Kathleen: has that changed? Tero seems to think so?
Tero: I have interest in everything..... even if experimental, doesnt need to be in WG because
     there are not that many people planning on implementing/modifying it. Not much point
     to go into WG.
PaulH: Kathleen, Yaron and I should talk and come up with some words on this
Kathleen: I do need more information from WG to see what is the right path. Implementations
         would be another factor. we do need to hear from everyone.
PaulH: we'll talk about how to ask the WG.
Kathleen: Lets do that within the next few weeks
Rod: just to be clear, we are okay with either.

end of meeting