IETF 72 Dublin IPSECME Minutes taken by Sandy Murphy Introduction Yaron Sheffer and Paul Hoffman Yaron New charter Fixed number of items with 24 month sunset Can then recharter, adding items to the charter PaulH Both chairs will be playing bad cop IESG was reluctant to charter another long lived wg so promised to stick to work items. Any new charter items must pass AD who will ask IESG New items after first work items are done (i.e., pass IESG) Make sure we produce good documents Agenda: 1. IKEv2bis status 2. Roadmap document 3. IKEv2 IPv6 config status 4. IKE session resumption status 5. IKE redirect status 6. ESP-null visibility 7. Out-of-scope-for-the-WG documents 8. Open mic on items from the charter 9. Open mic on non-charter items 10. Wrap-up First two items are the "m" part of "me" the rest are "e" part ======================================================== Presentation 1: IKEv2bis Status -- Paul Hoffman Immediately after IKEv2 publication -- started "clarification" document -- known problems with document as document went forward but no desire to delay the main document. Also not good to have 50 page clarification document Overview: - Where we are, where we want to be, how to tell when we get there, getting there more efficiently - No good idea of when to close up Current status of draft draft-hoffman-ikev2bis-03 - Obsoletes IKEv2 and the IKEv2 clarifications document - Pretty much didn't change almost anything -- some winking and nudging at that - Have already started draft-ietf-ipsecme-ikev2bis-00. - Structure of document has all the changes called out. - We think it is in good shape but it is not complete. - We have a lot of comments that came out of the clarification document -- are those going to live into the RFC? Handy for those who read RFC4306, but not for implementers who doesn't care about history. -We will take to wg: what would be most useful? Do we have an appendix of the changes or leave them in body. We are not getting about comments like "it says X but Y is true". We are getting editorials and "it is missing X and that is important". Some people have promised lists of open issues, so we know it is not complete. Slide of open issues, in no particular order: - One question of window size -- what changes window size - One question (already mentioned) about how to represent changes - One question about winding in Jari Arko's document of how to deal with ICMPv6 (Related to question of whether to put IPv6 in this document and whether in Pasi's document he will talk about later) - One question of what it means to say "MUST NOT" fail - Have a discussion of picking DH groups - Will take to mailing list Have to decide when to stop adding new issues. - How do we get more input Most developers are not saying what problems they are having. No one is telling wg of cases when they had interop problems because they misunderstood something. Please send in cases that were hard to interpret. Promise to preserve anonymity. Want to hear from developers who are doing IPv6. It is perfectly reasonable for us to punt on IKEv2 for IPv6. We don't have to wait now for IKEv2 for IPv6 but we do have to promise to do it What about EAP methods -- are you doing them all? None? Some? If EAP is growing like weeds and we can't do them all, what do we do? Some of you have shipped to customers, what are you hearing from them, does it work for your customer's remote customers? We can blind reports. What is the end state? - How do we tell when the document is complete Hard question because there are few deployed implementations other than OEMs, which ship with it turned off and hard to turn on Not hearing from people in ops area -- maybe they want us to finish quickly, maybe they don't. Suggestions to chair are desired "It has been going on for 5 years, it must be great" -- that won't happen, bit rot happens, bit rot happened on IKEv2. Other working groups may be interested in IKEv2 and want us to finish quickly Need another author Would like an implementer who has done IKEv2 and is still doing IKEv2 Q: Cheryl Madson: What guidelines do we have for what we are willing to change in the doc. Bits on the wire, expected results like success? Can we change doc structure Do we want it to look like 4306? A: We have degrees of freedom of what we can change. Present structure is close to 4306, but that could change. Interesting question, can we change the protocol? We don't have rules on that. People on wg list should say if their change is a change to the protocol. Q2: A goal to collapse into one document? -- Other wg want to use IKEv2 and want to look at a doc that explains it well. Not just developers. A: Other wg want to use IKEv2 for keying, how to set up things, etc. Our doc must serve them well. Since we did IKEv2, we've done mobike and some of that could be relevant here. Paul: how many people are here from another wg because they want to use IKEv2? A: two people spoke from mip. Paul: maybe we could open formal arrangements. Lakshminath Dondeti: Why are we mucking with IKEv2? Thought this was M&E. A: we don't necessarily need to, or intend to, the question is are we allowed to. Pasi: One clarification is a case where 4306 said two different things in two different places. Yaron: There's been a question of adding several of the smaller documents, whether they need to become part of IKEv2. My personal position is no changes to IKEv2 except for blatant technical problems. Tend to agree with Paul that we need to have guidelines of what we can change. Pasi: Charter says small fixes ok but absolutely no new features. (no name given): What about configuration changes to IKEv2. Paul: A new document is coming up. If the two documents finish at the same time, maybe they will fold together. We don't know about IPv6 configuration -- might be new work. Tero Kivinen: there is already something that came in clarifications that is actually a change about mandating using strong authentication if using EAP. Paul: Tero said it is not clear about new things that are not mandatory to implement -- do such changes go into this document. ======================================================== Presentation 2: IPSec Roadmap: -- Yaron Sheffer We have a charter work item that is a IPsec roadmap - Roadmap covers main specifications, extensions and algorithm documents for both 24xx and 43xx series - More general than 2411 -- which is focused on the recommended content of algorithm documents -- not what we want here - We want a guide to the jungle of documents, as a guide to implementers - Informational only, no extra protocol statements Food for Thought - More or less in line of what we're looking for: - LDAPv3: 4510, TCP: 4614, BGP: 1656 (minus the implementation experience sections which are borderline specification) - draft-ietf-pkix-roadmap -- extensive, expired, probably too deep on rational and wg history, history is not what we want - draft-ietf-sip-hitchhikers-guide -- very much the kind of roadmap we are wanting Q: Alfred Hoenes: dnsext wg is working on a roadmap. Might be interesting for this wg, to see what their discussion has been of content and structure ======================================================== Presentation 3: IPv6 Configuration in IKEv2: -- Pasi Eronen draft-eronen-ipsec-ikev2-ipv6-config-04 Background :IPv4 - (This is about remote access to home corporate network) - In IKEv4, gateway gives you address - It creates PAD entries chosen from internal pool, and authorizes IDi to create child SAs for this address (according to clarifications doc) On client: - Creates virtual interface with this address - Update source address selection info (eg routing table) for apps to use, creates PAD entries so IDr can create child SAs for this addr IPv6 versions of messages have IPv6 addr fields Problems with IPv6 version: - Doesn't allow multiple prefixes on same interface -- required in IPv6 to work correctly - Virtual interface does not have link local addr (violates MUST in 4291) -- some IPv6 protocols require link-local address (e.g., MLD) - Interface id selection-- some interfaces do care about the address they are given, gateway can't pick, client must pick (CGAs, HBAs) Design space has three dimensions: - Link/subnet model Point-to-point -- every client gets its own prefix Multi-access -- multiple VPN clients on same virtual link like Ethernet Router aggregation (NBMA) -- multiple VPN clients have shared prefix but not shared link - Layer 3 access control (how gateway drops packets with wrong source address) In IPv4 IPsec you negotiate SAs that contain traffic selectors that only allow certain address to be used -- reflected in SAD/SPD Ingress filtering outside IPsec (Pasi now thinks that keeping things inside IPsec is right idea) - What messages are used to communicate this addr/prefix to client IKEv2 config payloads IPv6 neighbor discovery messages DHCPv6 messages Solution space (extras) - Reauthentication: get same addr(s) or different ones? - Compatibility with other IPsec uses: when creating CHILD_SA, is it for the virtual interface or the interface IKE pkts are sent over? (When same IPsec implementation (as used for laptop VPN to corporate internet) is used for application host-host connections, maybe inside the tunnel, maybe outside the tunnel.) Not the problem for typical laptop case, but for other wg like those running routing protocols, not easy to distinguish the two cases. Draft recommends one combination, sketches 5 others in appendix A Recommendation must be discussed by wg now. Current proposal - Use point-to-point link model Each client gets its own /64 prefix, Simplest, no complexity of multi-link subnets A VPN gateway would need a large address pool, which could be a problem if you are creating a VPN to home and your ISP doesn't give you enough space - L3 access control inside IPsec SAD/SPD Aligned with overall IPsec arch Same as IPv4 -- limits difference between how IPv4 works with IKE and IPv6 works with IKE -- knowledge about address is in IPsec/IKE - IKEv2 config payload Same as in IPv4 case But specific to IKE (i.e., not doing IPv6 address allocation the way all other IPv6 uses do but can use stateless DHCPv6 for other configuration than addr) Gabriel Montenegro: there's a new wg called csi: would make cga address and DHCP work together. There are several efforts to change how DHCPv6 works. Theres's also DHCPv6 prefix delegation. Bob Moskovitz: just got native IPv6 allocation to home, got /48. don't think that's going to be normal. V6ops seems to think that /64 allocation to home is likely. Greg: how are you proposing to do DHCPv6 with IKE? Pasi: don't propose using DHCPv6 to allocate the address, get CHILD_SA independently of this, then use DHCPv6 to get the DNS address that's transparent to IPsec. Paul: cut Greg off: we're trying to describe problems, not the solutions. In the following three presentations, keep in mind that proposed solutions in the current draft are not necessarily what the wg will go forward Next steps: - Need new editor or second author -- Pasi is occupied with being AD - Particularly need input from implementers - Need more discussion. in particular, wg should consider the selections he rejected because that was not wg consensus Paul: if we end up with a document with no proposed authors, we will kill it ======================================================== Presentation 4: IKE Session Resumption: -- Yaron Sheffer Chartered work item - Session resumptions in a client-gateway situation -- upon temporary gateway or network failure - Client and a single gateway- or a closely synchronized (state sharing) gateway cluster - Motivation: CPU load of large number of clients re-connecting, re- entering passwords - Like TLS stateless session resumption Out of Scope for this document - Resumption into different gateway -- failover to new g/w - Detection of network/gateway failure -- will hear about detection in "out of charter" section of this meeting - Specification of "state" ticket. Starting point and Delta - Starting point: Lakshminath Dondeti, Vidya Narayanan, Hannes Tschofenig, called draft-sheffer-ipsec-failover-04. (Hannes to take over as editor) See also draft-xu-ike-sa-sync-00 - Minor changes to draft (like name) to reflect resumption, not failover - An ongoing discussion on number of round trips vs security guaranties Wg should reopen that discussion - Eliminate ticket format or weaken the language One part of the ticket is about failover, which is going away Ticket is out of charter and needs more discussion of what degree we can cover the ticket Ticket presentation - A single exchange for session resumption, and an additional optional exchange if gateway sees signs of a dos attack - Note: Use of temporary IKE SA for the back and forth At end of resumption exchange you get a whole new IKE SA that is derived from the original, not a copy of the original Second draft -- draft-xu-ike-sa-sync-00 - Much discussion of usage scenarios -- plus a load balancing scenario Major difference: Talks about database and gateway interactions with the database Whether to include that discussion should be discussed on mailing list Ahmad Muhanna: seems like only changes is the name (failover -> resumption) Hannes Tschofenig: not true. go back to resumption only (00 version), and fold in aspects about number of round trips which we later added. Failover case is rather different, whether you present some opaque state to the same box again or present that to a different box. Some of the security considerations will need to be rewritten because they are different between failover and resumption. Q: but you say about a pool of servers. Where is the difference? Yaron: pool of servers looks like a single gateway to client, it's a closed cluster, they share everything. Q: mechanism of sharing, this is not true?. Yaron: Not the case. Failover draft can deal with geographically remote gateway's. ticket is given by one gateway to client with list of other gateway and client presents ticket to new remote gateway, ticket is not shared between gateway. What is shared is master key to decrypt ticket. Q: but if ticket mechanism is out of scope, this is the same technique. Q: Not clear that ticket mechanism is out of scope ======================================================== Presentation 5: IKEv2 Re-direct Mechanisms -- Vijay Devarapalli IKEv2 Re-direct Mechanism - The re-direct mechanisms of IKEv2 allows a IKEv2 responder to redirect the client to another responder, mainly IPsec VPNs and mobile nodes to home agents - Typically redirect on overload, could also be due to subscription profile (e.g., privileged user) IKEv2 redirect mechanism - Client includes a payload saying redirect supported - Responder replies with decision to redirect -- could be address or FQDN etc - Client initiates a new SA with new gateway with info it got from first responder Use of anycast address - Means you don't need to configure specific VPN gateway's unicast address into the client, just anycast addr - The ike-sa-init request is sent to the anycast address - The response comes back from the anycast address, redirecting the client to a particular VPN gateway (source is the anycast address to get through the f/w) Initial responder must re-direct client to its own unicast address -- it must do this because a client response going to anycast address may end up at different gateway in the anycast pool - Con: you need another round-trip exchange Three new notification types (REDIRECT_SUPPORTED, REDIRECT, REDIRECTED_FROM) Open issue -- redirect during IKE_auth exchange - If you want to redirect based on a subscription profile, you have to do redirect during IKE_AUTH exchange because address of mobile node is not know until then. IKE SA with original gateway would expire. - Will post email to follow up on this one. Open issue -- gateway initiated redirect in the middle of a session - Requires an info message with the redirect payload from the gateway to the client - Should this be supported? Q: (no name given) Can you be redirected again if you get redirected once -- suppose you redirect because of heavy load and now the load is loading down the new gateway A: When you have a cluster, you have a management system that knows about the load, but this would be out of scope for this document. Q: Ahmad Muhanna: What is the value of the "redirected from"? A: If a gateway is misbehaving and redirecting too many clients, this provides a trace of the one doing the redirection. Q: (no name given) Why have limit to the initial exchange when setting up the IKE SA? A: the initial target was for load balancing so did not talk about mid-session redirect. Typically try not to get into state where you are overloaded and have to offload mobile nodes. Q: But traffic load changes over time, so it might be of benefit Q: Stefano: About the open issues -- is it just that there's been no mailing list discussion or do you actually see an issue? : A: No discussion on the mailing list, these were mostly from off line comments. Paul: All issues are open issues. We have no wg drafts at this point. We are starting with some drafts that match work items. All significant questions are open issues. Most new wg have clean slate, we have drafts that roughly fit some items in our charter. We will keep all these options open. We will have a question of when we close off the open issues. ======================================================== Presentation 6: IPsec ESP Extensions for Traffic Visibility: -- Ken Grewal Problem description: - Scope: traffic visibility for ESP traffic only Enterprise network monitors traffic so needs to be able to see header AH can be used but not NAT friendly and yes there are NATs inside enterprise environments -Current specs make it hard to differentiate ESP-NULL from ESP-nonnull Proposed solutions (two drafts) - New protocol wrapper for existing ESP packet format - Stateless, efficient parsing of ESP-NULL pkts using data within the pkt - Draft-hoffman-esp-null-protoocl-00 by Paul Hoffman Dave McGrew - Draft-grewal-ipsec-traffic-visibility-01.txt (Ken and Gabriel) (this is a charter item) Draft-hoffman-esp-null-protocol - 2 new protocols for identifying ESP-NULL (negotiated) esp-auth-only-no-iv esp-auth-only-8-octet-iv - IKE dependencies New transforms with new protocol numbers Draft-grewal-ipsec-traffic-visibitliy- - (incorporated comments from Paul and Dave and other offline comments) - 1 new protocol for identifying "Extended ESP" - UDP encapsulation compatibility for NAT-T ESP extensions - Standard ESP beyond first four bytes - Motivation: Intermediary device extracts everything that it needs (in stateless manner) from the first 4 bytes to identify upper layer payload -- and use for whatever it needs like ID system, etc - NextHdr: same as in trailer. From hardware perspective, easy to look at first 4 bytes rather than backward parse from the end of pkt. Visible in ESP-Null anyway, so no security issue. - HdrLen: Explicit value to offset from the header and jump to payload - TrailerLen -- may find useful UDP-Encapsulation - Motivation: Stay compatible with NAT-T work - Initially spoke of getting UDP port but that would have brought about inconsistency between IKE traffic and IPsec traffic (and another punch another hole in f/w) - Try to reuse existing 4500 port - There is a protocol identifier, which is your SPI field, following the UDP header, which is used as a demux between IKE traffic and IPsec traffic. - The value of 0 (reserved for IPsec) indicates the UDP payload is IKE - Propose to use another reserved value (TBD) there to indicate the extended ESP header Summary - Primarily for end-end IPsec deployments, enterprise environments. Enterprises do desire to use IPsec internally. - XESP critical to enterprise based IPsec deployments -- visibility to preserve your existing IT tools - Applicable to XESP only ( does not impact AH or ESP) - XESP wrapper concept is similar to NAT-T -- extends ESP instead of breaking it Yaron: we have a charter item on ESP traffic visibility and only one starting document - the ken/gabriels draft -- not Paul Hoffman's. Paul: we let our draft expire. Tero: why didn't you put the 4 bytes in the TCP option. Q: options not used for end-end Tero: It is not end-end -- and intermediate systems could see it. Paul: Proposed that early on, IESG said NO. Tero: why? Someone else: some devices slow down pkts that have options Ken: Apart from IPv6 extensions, options are frowned on, IP options are not on the fast path. As far as intermediate device adding an additional header, you still need to parse the packet to add the additional header. Steve Kent: when you add 4 bytes, is next protocol field the real protocol? A: Yes. SK: But that's not OK, we intentionally put it into the encrypted payload part. Ken: this is not encrypted, integrity only. SK: But there's an "integrity only" field. That means it does encryption sometimes. Paul: This draft is about integrity only, by charter. SK: It could confuse people with that ambiguity. Paul: That's a technical matter we'll fix. We can't change the charter to make this a new version of ESP. ======================================================== Now begin the out-of-scope items. ======================================================== Presentation 7: TAHI Project IKE v2 testing activity -- Yukiyo Akisada - Working on IPv6 tester for 10 years - Released conformance tester version 1.0a1 today - Covers all of MUST/SHOULD and clarifications - Covers end node or gateway - Free software and can be downloaded from http://www.tahi.org/ Overview - Virtual network in tester. - Tester can generate any IKEv2 packet and can investigate any packet from device under test - Load tester with pkt definition, virtual network, test procedure. Background: Started in Mar 2007 (slide has typo) Discussed with VPNC and ICSA Labs Please use our tool. Demonstration available at IETF. Comments are welcome, send to contact@tahi.org See www.ipv6ready.org ======================================================== Presentation 8: IPSEC Performance in bmwg -- Merike Kaeo Background - Working on IPsec performance docs in bmwg for 6 years - First started doing performance testing in 89-90 - Wanted to do some benchmark documents to standardize on performance testing. Got useful comments from implementers over the last 5 years and feedback. Current state: - IPsec performance docs in bmwg (absolute final version): Terminology for benchmarking IPsec devices Methodology for benchmarking IPsec devices (v4 RSN) - These cover only IKEv1 and manual keying - New separate doc to address IKEv2 Bmwg was not in favor of this approach, but IPsec engineers thought it was right Merike wants a co-author to work on IKEv2. She will continue to edit the documents as long as receiving inputs in a timely fashion. Official support, not just private email, is more effective. Paul: We will certainly have comments when the bmwg docs go to wg last call. ======================================================== Presentation 9: GRE Key as Traffic Selector -- Hui. Deng Requirements from operating experience - GRE Key is used as differentiator for overlapped private address consideration - Mobile standard like 3GPP has specified GRE key to differentiate the user in mobile ip tunnel - Some enterprises need different security policy for each connection tunnel - Could satisfy this need of mobile IP service provider with GRE key as traffic selector in IPsec tunnel Network scenario for GRE key based IPsec tunnel Mobility Access Gateway (MAG) and Localized Mobility Anchor (LMA) have several traffic flows between, identified by GRE keys. Some flows require security protections. Different flows go to different customers (enterprises or mobile nodes). It would be good to use different IPsec tunnels to protect different flows. Hence good to use GRE keys (which identify the flows) as traffic selectors for the tunnels. Work item? - Appreciate Pasi's help to make the proposal to charter - A standard track extension to IKEv2 to support using the key field of GRE pkts specified in 2890 as a traffic selector in similar fashion as TCP/UDP ports and such. - Allows different GRE flows to map to different IPsec SAs Paul: This is not necessarily a work item for this wg -- people can make individual submission to the AD. We have a backlog of work. Work can be done by going to the AD, but it won't be a working group item. We can work on these on the mailing list. Work can get done without being done in wg. ======================================================== Presentation 10: Fast and secure crash detection in IKEv2 -- Yoav Nir Crash detection problem statement: - Sometimes SAs get out of sync, eg when one side reboots. Recovery then takes minutes - Assume Bob has rebooted - Bob can't re-initiate the tunnel (maybe Bob is a gateway and Alice is a VPN client) - Bob sends invalid_ike_spi message, Alice sends liveness check to which Bob can't respond, so Alice sends liveness check a dozen times over several minutes. During which time Bob and Alice can not communicate. Proposed solutions - Birth certificates (7 years ago, no draft) -- actually signed timestamps or restart counters -- sent in invalid_ike_spi notification (see the QCD draft on the wiki for why this is not good) - SIR -- stateless IKE recovery (current draft) Alice queries Bob about the lost SA using an unprotected exchange with a stateless cookie. - QCD -- Quick Crash Recovery (current draft) Alice stores Bob's token during the AUTH exchange -- Bob can regenerate the same token proving it's really Bob, and authenticates the invalid_ike_spi msg. Could recover with session resumption. Need comments on which solution is better. Especially need comments from makers of small devices like mobile phone devices, etc. Are the requirements these impose on the clients acceptable. Yaron: There is a wiki for the ipsecme on the tools site. Includes all the out-of-charter drafts. ======================================================== Presentation 11: IKEv2 with EAP-GTC -- Yaron Sheffer IKEv2 with EAP-GTC - IKEv2 included EAP to support legacy authentication Supports legacy credentials, but not legacy infrastructure - You can have username/password with a number of EAP methods, like MS CHAPv2 - Does not let you do some useful simple username/password authentication, like name/password authentication into LDAP directories (common) - The draft explains how to do it with EAP-GTC -- and why and when it is secure - Somewhat controversial, but implemented by several vendors. Would like to hear from you, especially if you are doing it in your products ======================================================== Presentation 12: Sangjim Jeong -- Applicability Issues with Supporting IPsec NAT-Traversal Mechanism in NAT-PT Overview - It is possible to support IPsec in NAT-PT based on 3948 and 3947 - Issues when applying them to NAT-PT IKE negotiation issue (ID type that is IPv6 would be a problem for an IPv4 only receiver) Solution is to use ID_FQDN as ID type value Transport mode ESP/UDP encapsulation issue (TCP/UDP checksum must be recalculated by NAT-PT, that relies on NAT-OA, which contains a IPv4 or IPv6 address type, so there's a chance of address type mismatch) Why revisit IPsec support in NAT-PT since NAT-PT mechanism has been deprecated - Efforts to redesign IPv4/IPv6 translator in v6ops wg They are working on problem statement and requirements drafts Problem statement draft: IPsec support is mandatory (3948) Issues of previous slide may need to be reconsidered ======================================================== Paul: two question sessions: one on in scope topics and one on out of scope topics First: questions on in scope topics. Greg: channeling for Dan on jabber: about resumption/failover. Since ticket content (or not) is very important for security why is ticket out of scope. Pasi: not in charter. If it is of interest, ticket format can be specified in separate document. Explanation of why not in charter -- vendors say a doc won't produce interop, as state in gateway will be implementation dependent.. Paul: but content is a security concern. (or things not in content) Pasi: Suggested content, but not format, is in current document. Paul: Can we say ticket must have these items in it, regardless of format. Pasi: There might be state in the gateway, and the ticket could have an index to the state. That's not prohibited. Greg: In IFARE BOF, considered trying to document use cases. Would love to do thata and then decide what was in and out of scope. Paul: could be useful. We would know when we are done scoping the use cases when we know which have security issues. Pasi: Failover is out of scope so IFARE BOF is out of scope. Vidya: Ticket content has security impact, so there needs to be mandatory requirement of what needs to be there, whether in the ticket or in the state in the gateway. But we don't need to worry about format and interoperability. To answer Greg: the resumption work should be independent of the use case, workable in any use case. So documenting use cases of limited use. Yaron: RE: change from failover to resumption. It would be great if same protocol could be used for failover. I don't want to have to do a different protocol for failover, even at the cost of performance Vidya: what is the difference between failover and resumption? Yaron: Jean Michel brought up: do we have gateway to gateway interoperability, and the answer for resumption is No. Paul: if you have multiple gateway that aren't distinguishable to the client, that's one gateway and that's resumption. But if it has to have an interoperable gateway protocol, that's failover. Hannes: For example, in SIP there are load balancing between servers but that is not visible to the client, it is a replicated mechanism. In other cases, there's an interoperable mechanism and that is what we are excluding from the charter. Vidya: So it looks like one ip address? Paul/Hannes: yes. Vidya: That limits usefulness in my view. X(no name given) For our work, indexed based session resumption, that ticket is different from the format with SA, the ticket is more simplified and safer for our consideration, so we recommend to not define the ticket format Ahmad Muhanna: If you combine resumption and redirection, you get failover Paul: Yes, in a couple of steps. Ahmad: We are saying we support failover in some cases (pool of servers), but if you have different IP addresses, use redirection. Yaron: We could combine resumption, redirection, and crash detection into one monster RFC. Could be right engineering way to do it, but we wouldn't finish it. Jean-Michel Combes : if you wanted to do resumption with same gateway, the same problem may recur as to why the gateway was down. Someone attacks the security gateway and if you set up SA again, the same attack could bring down the gateway again. If this is a hardware problem, maybe you can't set up again quickly. Paul: Yes, this problem is intended to set up SA really fast when the hardware failed and resumed and you have some saved state. Also addresses network failure. Not generic (e.g., not covering failover to other boxes). Does not address the securing/underatttack issues you mentioned. JMC: So this proposal will not concern all problems that might occur. Paul: True, but we should list the ones we are. Pasi: We are solving a much smaller problem than in the IFARE BOF of a couple of IETFs ago. Hopefully, that way we will finish. Trying to solve everything at the same time does not work. ======================================================== Questions related to out of charter work items. Steve Kent: I want to reiterate comments on list about GRE key traffic selectors. 4301 shows how to use multiple SPDs and use those for different clients hooked up to an edge device by ISP and select among them for different sorts of traffic. Authors need to show how their needs are not addressed by those existing mechanisms. Peny Yang: traffic selector for IKEv2 -- in 3GPP having GRE traffic selector for IKEv2 is important. Would like for this kind of problem to be a charter work item. Frederick Detienne: This comment is about GRE traffic selector and something related to IPsec with IPv6. Slide mentioned sub-interface for IPsec tunnel, IPv6 tunnel. Not something all implementations do -- even on same operating system for same IPv6 tag we may or may not have an interface. Binding of IPsec stays with interface itself which may actually provide a solution to the traffic selection for GRE keys. If you have an implementation that doesn't support this binding, it is less obvious how you do this binding. In some implementations it may be easy to link a given traffic selector or SA to a given tunnel. In others there may be overlapping in the SPDs and it may be more difficult to distinguish between the keys. IPv6 traffic interface binding. The identity binding would do the work of the GRE key. Would this notion of interface in the case of tunnel mode become mandatory? Pasi: this draft talks about case when VPN gateway assigns an address. If you don't assign the address to a virtual interface, to what do you assign the address? Where do you put that address so applications can actually use it? What does gateway do with the addr. FD: That is exactly the problem. The virtual interface is not compatible with IPsec SA. Some things you can do with SA you can't do with an interface, and vice versa. In IPv6, without an interface it is difficult to decide to encrypt ICMP ND message. But on receipt, if you don't receive an address inside the tunnel you have problems. IPsec tunnel mode should be linked to an interface and have an address. Pasi: There is an RFC that talks about modeling IPsec tunnel mode SAs as interfaces, meant for router to routers. Not related to this work. All implementations that use configuration payload to get an address have to have a virtual interface so that the applications can use that address for TCP which requires address to be in some sort of interface. Whether all IPsec tunnel mode SAs would be modeled as virtual interfaces is beyond this draft.