1 IPsecME WG 2 Interim Meeting 3 2009-09-22, across many different timezones 4 Using TeamSpeak for voice 5 Co-chaired by Yaron Sheffer and Paul Hoffman 6 Minutes by Paul Hoffman 7 8 Slides and agenda are at http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/Interim20090922 9 These minutes only cover things not in those slides 10 Recording is at http://www.vpnc.org/IPsecMEinterim-2009-09.mp3 11 12 Attendees (virtual bluesheet): 13 Dave Wierbowski 14 Dragan Grebovich 15 Gabriel Montenegro 16 Guy Snyder 17 Hannes Tschofenig 18 Jean-Michel Combes 19 Jouni Korhonen 20 Julien Laganier 21 Kalyani Garigipati 22 Ken Grewal 23 Michael Richardson 24 Paul Hoffman 25 Peny Yang 26 Raj 27 Richard Graveman 28 Scott Moonen 29 Sheila Frankel 30 Tero Kivinen 31 Yaron Sheffer 32 Yoav Nir 33 34 Agenda bash, document status 35 Yaron and Paul 36 This is an official interim, we follow the same rules as a regular f2f meeting 37 Start with short reports on current documents, minus AES-CTR 38 No changes or additions from the room 39 draft-ietf-ipsecme-ikev2-redirect has been approved for RFC production 40 draft-ietf-ipsecme-ikev2-ipv6-config is in AD review 41 42 AES-CTR 43 draft-ietf-ipsecme-aes-ctr-ikev2 44 Discussion by Yaron 45 Is in WG Last Call 46 Need more comments 47 48 ESP-null heuristics 49 draft-ietf-ipsecme-esp-null-heuristics 50 Discussion by Tero 51 There are a few more comments, there will be a revision 52 53 Roadmap 54 draft-ietf-ipsecme-roadmap 55 Discussion by Sheila 56 Combined algorithms for IKEv1 and IPsec-v2 57 Scott: thinks it's fine to do in IKEv1 58 Sheila: We can assume that we are using IKEv1 with the new IPsec 59 Tero: Should be able to used. 60 Sheila will add wording to make using IKEv1 less murky 61 Does IKEv2 truncate its ICV? 62 Scott: Some IKEv2 transforms are defined for both truncated and non-truncated forms 63 Sheila: Can you negotiate either form? 64 Scott: Yes 65 Tero: Non-truncated version is mostly used only for FibreChannel 66 Do whatever the negotiated algorith says 67 Sheila: Should we put something in the doc about the two forms? 68 Paul: Yes, add a clarification, and we should add that clarification in IKEv2bis 69 Paul: Keep moving, don't wait for IKEv2bis 70 Use of AES-XCBC in IKE 71 Paul: It sounds like RFC 4109 needs to be revised 72 Yaron: Roadmap should say that it is currently undefined 73 Say that it is a bug in the spec 74 Internet Drafts included in roadmap 75 BEET has encountered resistance in the IETF, and it might be abandoned 76 What about expired drafts that will never become RFCs 77 Some were not progressed because of security concerns 78 Tero: If you implement road warrior with IKEv1, you have to support both drafts 79 Most support some version of the drafts 80 Hannes: Maybe this means this should be an Informational RFC 81 Tero: But there are serious security problems 82 If people move to IKEv2 we don't need these 83 Adding some pointer to the drafts, but think hard before implementing them 84 Say "there is a good reason why they are expired" 85 Paul: Not true that everyone needs to implement them. 86 VPNC sees only about half the vendors have implemented them. 87 Worse, people have implemented them incorrectly for what they indicate they are doing 88 There were other ways of doing XAUTH that did get into implementations 89 Say "There have been various ways of doing configuration and extended auth" 90 But don't list any drafts 91 Michael: We have to mention them and say that they were bad, the ideas are in IKEv2 92 Would like th see the two drafts put somewhere and listed as "do not implmement" 93 Yaron: Supports Tero's position, do need to metion them by name 94 Tero: Wants a big warning that they are not safe to implement 95 Sheila: Will add text to mention the problems in the IKEv1 description 96 Paul: We will need a second WGLC on these issues anyway 97 Camellia for IKEv2 :undefined (no RFC) 98 Tero: We use the same IANA numbers for IPsec and IKEv2 99 You get the IKEv2 number automatically 100 Hopes that the combined mode doc for ESP can be used in IKEv2 101 IKEv2 tells how to use CBC, and the same for combined mode 102 Wanted this for the AES-CTR 103 Paul: Concern for making CTR generic is that we can only do it for what we know today 104 People can write short documents if they want a CTR mode for a function 105 Tero: The Camellia people failed to make their document specific enough for IKEv2 106 Wants to limit the number of RFCs for cipher 107 Paul: Agree that we don't want separate drafts for ESP and IKEv2 108 Disagree about wanting to limit the number of RFCs 109 Yaron: Are there others? 110 Tero: No 111 Yaron: Then let's leave the AES-CTR alone and let the Camellia people do their own thing 112 We need to open each of these issues in the issue tracker 113 No formal WGLC again, but need to close out the new issues 114 Then have a new document and go to AD 115 Will reformat the document to help make following specific documents easier 116 117 Session resumption 118 draft-ietf-ipsecme-ikev2-resumption 119 Discussion by Yaron 120 Peny: Understands that resumption detection is out of scope 121 Maybe we can have more text to discuss the risks of not detecting resumption 122 Paul: Wants specific wording sent to the list so we can decide if it should remain out of scope 123 Yaron: It needs to remain out of scope 124 There are already two drafts on how to do quick, secure detection 125 Doesn't want the proposed new text to be so specific that it would show preference towards one over the other 126 Paul: Maybe have the issue brought up in the Security Considerations 127 Yaron: There is a new section in -08 that may already cover this sufficiently 128 Paul: If Peny has specific issues with that new text, please bring it to the list. 129 Peny: Wants to know the rationale for 4.3.4 for silently deleting old SA 130 Maybe the gateway can just reject the resumptions request 131 Yaron: This is an anomalous case where the client detects a failure but the gateway is not sync'd 132 It does not mean that the client is mailicious 133 There is nothing you can do with the old stuff, so you just delete it 134 Peny: The client might have been deceived 135 The gateway should not have to delete it because there is more work for the gateway 136 Paul: Disagrees that we need to worry about how much work the gateway has to do 137 Tero: From the client's point of view, it has lost its SA, and that's why it is resuming 138 The gateway should assume the same thing, namely that the client has lost its SA 139 There is no reason to send a delete on the old SA because it is dead 140 Also: the client is asking for conflicting traffic selectors, so get rid of the old ones first 141 Peny: Disagrees that the client would only do resumption when it has lost the SA 142 Might do it when it detects the failure of the gateway 143 Tero: If the gateway has failed, it has no SAs up 144 Paul: Please take this to the list 145 Peny: Brings up old topic 146 Paul: This is not a good place to be discussing this 147 WG chairs are tasked with deciding consensus 148 If you disagree with a consensus call, take it to the AD 149 150 WESP 151 draft-ietf-ipsecme-traffic-visibility 152 Discussion by Ken and Gabriel 153 One proposal is to have flexible padding length 154 Pad lengths can be extended in the future 155 We know we need pad of four bytes for IPv6 156 Tero: How are you planning to handle for the IANA registry? 157 IANA registry will have bit numbers, but not the pictures 158 Gabriel: The whole field is called the Flags field 159 Lots to discuss on the list 160 Yaron: Padding options looks too complex, would prefer one bit that means "extra four bytes" 161 Tero: Agree 162 163 Possible recharter items 164 IPsec/IKE High Availability (draft-nir-ipsecme-ipsecha) 165 Discussion by Yoav 166 Tero: Doesn't think that the IKEv2 state needs any help from the other end 167 Sync channel will not be problem for IKEv2 messages, but will be for ESP 168 Yaron: The proposal is not to have just a problem statement like this document 169 We want to have a solution as a WG item 170 Tero: Doesn't think this a problem big enough for a WG item 171 Kalyani: Thinks that this is a big enough problem in many scenarios 172 Tero: The sync channel has not been a big issues for my customers 173 Doesn't need protocol help 174 Raj: May need protocol help 175 Yoav: If there is a failure, it is much harder to sync the HA 176 Need some help here 177 IKEv2 message ID and HA 178 Discussion by Kalyani 179 Yaron: Please use the standard Internet Draft format in the next draft 180 Raj: If we implement this solution but not in a cluster, it looks like session resumption 181 Kalyani: This could also be used for resyncing peers (gives scenarios) 182 Paul: We need a draft in front of us in order to continue the discussion 183 184 IKEv2bis open issues 185 draft-ietf-ipsecme-ikev2bis 186 Skipped the presentation because we only have ten minutes left 187 Certificate issues came up in issue #107 188 Presentation by Yaron 189 Yoav and Yaron came up with a list of possible issues 190 Tero: Maybe allow hash-and-URL along with bundles 191 Need to consider what will make things simpler 192 We will have a bunch of new certificate issues on the list 193 A new draft of IKEv2bis will be out early the week of 2009-10-05 194 We know that some issues will be re-opened 195 We are slipping from when we wanted WG LC, but the reasons are good, namely that we are hearing good implementer comments 196 197 Finished in two hours