IPsecME WG IETF 88, Vancouver Monday, November 4, 2013 Paul Hoffman (PH): We want the WG to agree on one of the three proposals, so we can start work on that one Sean Turner: uplifting RFCs to standard(?) PH: Sean Turner (outgoing AD) has taken it on to turn RFCs into full standard PH: Status report. Valery Smyslov: fragmentation draft, waiting to submit post LG changes. PH: often insufficient discussion. this fragmentation draft saw good discussion PH: other doc in WGLC, signature-auth. in WGLC, pretty significant. please review Sean: bookkeeping exercise. progress ipsec/esp/ikev2 . rfc5996bis. Don't change whole protocol. is that useful? 4301 to 5996. (AH situation - used elsewhere, left by us ?) Steve Kent: update on AH done, Sean told me not to submit. Do we want to keep it or not? Sean: multiple implementations of AH are out there. Anyone have objection to AH? Steve Kent: null-esp still mandatory (doesnt care much about AH) Yaron Sheffer: Actually, I'm to blame. Yaron Sheffer: mic: I'd like to discuss AH on the list first. PH: interoperability report. people willing to help. various heads nodding. Steve Kent: too late. pushed button Steve Kent: volunteer Shiela? dont you have automated testing rerpots Sheila Frankel: long long time ago. ikev1. does not run anymore Tero: algo updating . is that part of this process or separate PH: separate. these are for standards track Tero Kivine: other documents might need to be updated, for example [mumble] PH: Let's not push for those, the crypto algos. we dont need to spend our time to push those to internet standard. goal is other standards orgs want to use our stuff. this is not a problem for algo rfcs PH: update ikev2 crypto requirements Yaron Sheffer: mic: do we have a good example of an interop report that people can look at to understand the scope? PH: yes we do Tero prefers separate document for rfc 4307 update. reason: they might move forward in different times PH: reason to put algos the same doc. Because some are in user, some in kernel. Tero: volunteering seperate draft if needed PH: comparison AD VPN proposals now. we need more non-document authors to read these PH: pick one and move forward. work will start than. Yoav Nir: [ handing over child SAs following re-authenticating IKEv2] Valerie: can auth methods be different? Yoav: yes, but the "same" could included auth method Yoav: new cert with same CN= ? local implementation Dan Harkins: I dont think this is a good idea. A reason to get a new IKE SA would also apply to child SA Yoav: child SAs could be shorter and rekey more often, depending on volume Tero: I don't really see a use for this. You keep old one, negotiate new. then delete old one. no traffic interruption. Vishwas Manral: does not cause an increase in resources required? Tero: it does temporarilly. actually it does not. create one, delete one. not all at once in duplicate PH: please bring this to the list - it is fundamental Tero: when counting for "max SAs" this is lots of extra code. This seems lab scenario. could be experimental Vishwas Manral: [ draft-mao-ipsecme-ad-vpn-protocol ] Gustav (?): NAT-T assumptions are not realistic. Requires ADC+ADS+NAT at the same box. no phased-in deployment Tero: [ various reasons it can be okay already ] PH interferes in various people vehemently speaking about NAT-T - points them to the list Steve Kent: does the document describe in details how the spoke updates the SPDB when there is an update for the SA to take part of 0/0 to a new spoke? Vishwas: we have mentioned it at a high level, more details might be needed to address specific scenarios Brian Weis: support for large scale? How do you get large scale for ADS? Vishwas: bottlenecks are routing protocols themselves. not ADS/ADC. ADS not a single point of failure. It is logically single, but physically distributed. Brian wise: some AD -> hub information is sent. Why not sent everything to everyone? Why not have ADS to the hub everything? Yoav: registration page: can ADC claim any protected network? That's google's addresses? Can you steal? Does ADS have information to allow it to reject bad registration Vishwas: no. Policies in ADS could have policies and registrations and reject. Yoav: step2 what does that contain? Yoav: message ADS to ADC has to include all hundreds of subnets? how does ADC learn this? Vishwas: subnets of what's behind what peer is at routing layer (eg GRE, routing protocols) Robin Wilton: control and data plane [.....] allow to use same and/or different mechanisms. Give guidance Paul (?): during registration ... How is ADS trust worthy? Vishwas: where is the root of trust for ADS.... Gustav: netconf draft juniper talking about this with reverse call. netconf people not convinced. maybe we need non-security people to discuss these things Daniel Migault: is there exchange between two hubs? Vishwas: no. Go via the hub. we will handle hub to hub communication later on. Yoav: [draft-sathyanarayan-ipsecme-advpn-03] Daniel: we do work with NAT, some cases are hard to handle Paul Wouters: are these SHORTCUTS suggestions or orders? Yoav: it can fail or not happen for whatever reasons. Mike Sullenberg [draft-detienne-dmvpn-0] Steve Kent: ipsec sees gre as the next protocol layer? Mike Sullenberg: correct Steve Kent: turns ipsec into access control mechanism with encryption Michael Richardson: we have ignored channel binding. its great, a virtual network solution. its link layer encryption Completely ignores the SPD. [some say no]. Steve kent: We accused MPLS of things, like being a tunnel - we come close to doing the same Michael Richardson: that what you said sounds confusing. like you sent ethernet over gre. it is an option but you are not doing that? Not suggesting you do it (build a L2 encrypted VPN) Steve kent: correct Robin Wilton: setup more clearly which provide end to end and which provide tunneling PH: the most inner layer is that tunneling and routing or .... Steve Kent: moving spd into the routing layer, there is a security issue that needs to be addressed PH: We'll keep this discussion going for at least a month Sean Turner: your way forward is good. hope all authors will come together during this discussion PH: need enough non-authors to make choices and understand/question Yaron Sheffer: mic: fully agree with Paul about the process. Thanks. Daniel Migault: pretty important non-authors asks things PH: authors need to feel okay to express opinions but not dominate Michael Richardson: i prefer any solution that works with mostly just ikev2. If it involves new kernel/protocols, that becomes a big deal to get it deployed. Require only an update to ike daemon is important. lou's: routing proposals coming in .... fixme Paul Wouters: worried about mixing single device and site-site and 0/0 to 0/0 fairy dust Yoav: why is ADS needed in [xxxx] proposal ? Seconding Brian's questions Andrew Sullivan: ADS. concerned it is a point of failure. even if physical disperse, logical single entitities cause synchronoization issues. Distributed database behind it is the DNS. We took that as part of our model Yoav: we have DNS but also "google". distribution works with sufficient resources as much as you wish to invest Brian Weis: 3 different use cases in requirement document. Worried any one of these proposals fits all three. Steve Hanna: it might be helpful to have each of proposal teams describe in more detail how their proposal would address the 3 use cases? PH: I think that would be good Brian: That's a great idea. [Sean puts hands out for good procedure] PH: Thank you all - continue on the list