[IPsec] Draft minutes of the Maastricht meeting

[Yaron Sheffer <[e-mail]>]

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 ???