Below the minutes. Clarifications/corrections are welcome.
Thanks to Jim for taking extensive notes during the meeting!
Yaron
---
IPSECME Meeting Notes
Note taker: Jim Schaad. All remaining errors by Paul and Yaron.
Agenda bash & Status
- IPsec is due to change from MUST to SHOULD in the new IPv6 node
requirements doc.
- Ongoing discussion on using CGA for authentication, some aspects
relevant to IPsec.
HA Recap slides
People should read McGrew's msec counter mode document, now in IETF
last call. [Pointer sent separately on the list.]
RFC5297 - Auth encryption mode is another solution (a different
block encryption mode).
HA Solutions slides
Steve Kent - cluster member taking over shoves done and peer
response as needed.
Paul - Each SA is synced up independently.
Steve - Should be indication of knowledge of more SAs to be synced later
Raj - "More" flag indicates that more SAs are coming
Paul - Nothing about what happens if "more coming" flag is not set
Raj - peer can initiate for secondary SAs (?)
Dave McGrew - How is a replay attack possible? [offline commentary:
ESP replay is in principle equivalent to replication of packets by the
network, and thus not an attack; however the draft attempts to preserve
existing ESP security guarantees.]
Raj - Lost IKE SA so counters can be reused - must fit in IKE window
DM - ESP and AH - possible attack here?
R - After failover happens can safely stop traffic
DM - expand
R - Active member sync w/ standby - counter =1700 = now counter is
1800 - standby starts from 1700 (last sync) looks like replay attack to peer
Yoav - Sync counters every 1000 must - peer can now resend message
1001 again after failover since does not know that it exists.
DM - situation where cluster is not following RFC [each gateway is
compliant, but the cluster as a whole is not].
SK - cannot go 100% HA - could toss on floor or accept possibility
of replay
Yoav - could send one message to skip forward on all IPsec SAs, then
peer just jumps forward and can do all SAs at the same time.
R - different data traffic on SAs - so possibly different traffic rates
Paul - just not full IKEv2 - similar to concept of your other side
might have forgotten something and you need to re-sync - not currently
specified.
Tero – there is a real replay attack remaining, rate limiting does
not help at all - replay counters where set back anyway - peer should
know better as window is not matching well. This is my counter - peer
should send my feeling of counters – and then send back larger numbers -
change in design.
Yaron - Rate limiting does not solve problem - should solve at the
transport and message level - not semantics of the payload – one option
is to have a “failover counter” that's incremented on failover events.
Dan - What is the protection against bad packets from an attacker –
can this cause a resync
R - Must be preceded by a failover event detection
R - addressing rate limit w/ special Message ID 0
Tero - Protocol should be split into two parts - IKE SA and IPsec SA
counter syncs - different ideas of how they should be working.
Problem IKE SA syncing - assume we missed some message - just need
to sync counters - need to look at what those messages are really doing
– need all changes to active SAs. Need text to say what happens for each
different type of message. Easier to sync the SA counters when they occur.
Paul - If two parts of cluster are not sync perfectly - the wrong
picture on the failover server coming up. Risk is high and better to do
a full re-key when states are wrong.
Tero - don't need message id 0, just a normal IKE message and continue.
R - Not possible to send a normal IKE message because of out of window
T - Want to kill IKE SA if out of window. If two are out of sync -
fall-back comes up - normal message ids - everything but a couple are
out of sync - those few can be re-built from scratch.
Yaron - quantitative question - DPD wants to happen a lot in some
cases -IKE brittleness [dependence on exact counter sync] will be a
problem and go out of sync - could be a high percentage of SAs out of
sync. If only for real traffic that causes a sync failure - then maybe
don't need all of this work.
Paul - ? - cluster member knows what type of syncing is occurring –
if Tero style SA [few DPDs] then don't need to do this type of work.
Based on the type of message then this is needed?
Yaron - Yes -
Paul - could make this a runtime situation decision.
Tero - Why would you want to send lots of DPD message? - If no
reason to be doing this then changes the issue for this document.
Paul - Not relevant - cluster member has lots of things to look out.
Tero - Protocol is useful if IKE messages much more frequently than
sync messages. Otherwise this is not useful.
Paul - Cluster member should have a feeling [re: traffic rates and
composition].
Tero - no just the IKE part is not needed.
Paul - missed that - in splitting the IKE part can be removed
Yaron - DPD issue is not a morality question - protocol allows for
them, they will be aggressively used and thus we need to deal with this
issue.
Paul – aggressive DPD seen “in the wild” in existing products
R - different peers can be sending DPDs as well. - including clients
- this is a cluster - other messages that occur - could miss a rekey
early than needed?
Tero - no that does not help -
R - arguing why IKEv2 part is needed - enables DPD - childless SA -
rekey may occur earlier and then try
Paul - sense of the room -
who read it - 10 people
Splitting request - how many people think this makes sense - more
people think spiting makes sense. Let's hold on the kill of IKEv2 until
after the split discussion is finished.
Tero - Does not solve all security problems - IKE part - sends
biggest message id sent - forgets everything in the current window -
sends biggest replay to date.
R - protocol does not say ignore all message
T - doc says forget all message
R - allows for rekey questions
Yaron – security should not depend on higher level semantics - need
to not allow for replay of messages - could make it a multiple (3 or 4)
message exchange
T - does not clarify what is going on - Peer thinks an on-going is
processing and could get the replay prior to an SA response coming back
(via different and slower routing)
P - Please send to list - assume split occurs and send multiple sets.
Yaron - separate security infrastructure
Brian Weis - Solving replay problem is extremely important - w/
nonces will be requirement - how much do we save over the rekey if we go
to multiple messages? - different between child SAs and IKE
Yaron - if splitting then the multiple message game is just for the
IKE SA part
T - IPsec SA syncing part. - why we need to the maximum. - goes
away if message id 0 goes away - currently document says - when failure
sends out counters - says this is the biggest counter I have seen
to-date - Peer sends back to and may have a lower counter and thus
replay back to the peer.
R - not to have a crash counter because one more state is required
to have and must be maintained by the peer as well as the cluster.
T - solving replay is more important than making the optimization in
the peer.
P - design team has over optimized - may need to be removed
T - Text saying counters are incremented [should say, “incremented
by a large number”]
P - wording issues
T - if not large enough number incremented - then peer knows it is
higher - thus a replay window has been opened.
P - Section 8 needs to be re-written. Was surprised by some of the text
in section 8 on first read
Yaron - questions -=
In favor of making it a working group draft - some hums
no one against
Failure Detection Decision Process
Raj - If we can detect the crash and do retransmissions - most of
the job is in the gateways - crash detection can be important - offloads
some work to the client or peer - helps load balancing w/ loose clusters
– see applicability of this.
Paul - do you see this valuable for which end of the cluster
R - see value in both sides of the connection
T - quick crash recovery is desired - but good implementations can
do this - don't need protocol support for this - QCD does offer
something - but SIR offers nothing. Don't agree same MITM attack level
in SIR as in normal IKE. Looking at slide 4 - none of these proposals
addresses the second bullet item. Bob does not know anything about Alice
anymore.
Yoav - QCD and SIR have been in draft form for 3 years- The idea of
“birth certificates” was mentioned ten years ago on the list but never
materialized as a document. Crashing on clusters is not as big of an
issue. Could be an issue for single gateways however.
R - Different types of clusters - load balance can be an issue as well.
Yoav - w/ IKEv1 we could solve this in the protocol - setup the
delete message and stored it on disk. could then pull up message and
send the delete messages when things looked weird.
Would be needed because people are trying to do it.
Basil- QCD would be better
Yaron - does this imply it is needed
Basil - yes I think so - cannot be addressed simply -
Paul - short round on the list - but crash detection effort will
probably die w/o much support showing up.
SEED in IPsec [short presentation on the new document].
Labeled IPsec - Jarrett Lu - new document will now be published.
Paul - Please let us know at the start and the finish of this
type of work so that we can do some review - but the discussion is not
on the mailing list.
PAKE - Sean Turner
Will go forward with PAKE as IETF stream Experimental [possibly
multiple different solutions].
Will push as it comes up
Dan: - willing to start screaming bloody murder now [over the
decision to drop PAKE from the working group]
This working group is generically quiet - three different
reactions to different documents
EAP only got no comments - and is moving forward
Liveness [crash detection] - concerted decision to cheer-lead
PAKE - lack of reaction except from author - caused work item to
be eliminated
Three outcomes from basically same response of the working group
Paul - did cheer-lead for PAKE as well. will end up with similar
results - correct on pushing some with too little discussion out the
door – now considered a mistake.
Sean - some may be naivety on my part - newness on the IESG.
Paul - think PAKE is much bigger than the EAP mutual
Tero - biggest PAKE problem is that most people not able to select
between the different docs - need to have a single document to choose.
Force the authors to pick.
Paul - good response [by the authors] on the list - best response
except for asking some to die.
T - see if there is now a common single document that the authors
can agree on. Think authors are currently the best ones to do the selection
Paul - will see if this can work
Yaron - think if one proposal can have more support?
Paul - Question if have a single PAKE - will you spend more time
on this document? 3 new people.
Radia - Do we understand the IPR situation? Suspect that is some
of the disinterest in this topic.
Dave - tend to use strong secrets for authentication [in storage
applications] - understand that may be stronger derived from weaker -
will look at a single draft.
Radia - Might be a good idea given the EKE patent might expire
soon - that this might be the best way.
Yaron - what if the authors say it is good [as far as IPR]
Radia - not good enough unless some type of legal protection involved.
Yoav - failure of the working group system if the WG cannot decide
between different proposals. WG is no longer bringing value into the
process.
Paul - Does not mean anything on the experimental vs standards
tagging.
Imachin (?) - PAKE author - Think it might be better for the
authors to present proposals at the next IETF.
Paul - tired of wasting time and we have done that in the past and
it did not seem to move forward.
Yoav - how do we avoid this situation for the QCD vs SIR vs the
virtual birth certs ???
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
