IPsec ME minutes IETF 91
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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
