draft minutes from wg meeting
Barbara Fraser <byfraser@cisco.com> Mon, 22 July 2002 19:51 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6MJpIw04440; Mon, 22 Jul 2002 12:51:18 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03180 Mon, 22 Jul 2002 14:59:03 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020722120501.0322f738@mira-sjc5-4.cisco.com>
X-Sender: byfraser@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 22 Jul 2002 12:11:22 -0700
To: ipsec@lists.tislabs.com
From: Barbara Fraser <byfraser@cisco.com>
Subject: draft minutes from wg meeting
Cc: byf@cisco.com, tytso@mit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi folks, Here are the draft minutes from the wg meeting. Please send any corrections to me in the next week. I plan to submit these along with the slides next Tuesday, July 30. Many thanks to Dennis Beard for taking such detailed notes! Barb Wednesday 7/17/02: IPsec WG (afternoon session) Minutes taken by: Dennis Beard Barbara Fraser and Ted Tso are the co-chairs of the IPsec WG. For this meeting, Barbara was the single Chair. The meeting began at 15:30. Status of current document - Barbara Fraser 15:30-15:35 Agenda bashing - Fraser 15:35-15:45 Status of current docs - Fraser 15:45-15:50 Nat-T - Dixon 15:50-16:00 IPsec and mobile IPv6 - Dupont 16:00-16:05 Latest AH draft - Kent 16:05-16:10 Multicast and IPsec - Kent 16:10-16:30 SOI Discussion Summary - Kaufman 16:30-17:15 Open Mic 17:15-17:30 SOI Proposed Schedule - Fraser 17:30 Adjourn NAT-T - William Dixon Due to a misunderstanding of presentation scheduling, William had no prepared charts. He did, however, brief the WG on the latest status concerning NAT-T drafts. The technical drafts are now in last call in the IPsec Working Group. They are: draft-ietf-ipsec-nat-t-ike-03.txt draft-ietf-ipsec-nat-reqts-01.txt draft-ietf-ipsec-udp-encaps-03.txt Latest changes include the following: Draft-03 versions submitted to update the author list and make some clarifications. The draft-ietf-ipsec-nat-t-ike-03.txt did change the Vendor-ID string to represent draft-03, although there are no changes that would make it interoperably different from draft-02, except the vendor ID. Vendors, which have implemented draft-02, should accept draft-02's vendor ID. If recent implementation was done according to draft-03, send the vendor ID for draft 02 as well to interoperate. Note however, the vendor ID string in draft 02 was wrong for the hash value. Implementers should use the MD5 hash hex value, not the string to interoperate with other implementations. Draft-ietf-ipsec-nat-reqts-01.txt was updated March '02. There are clarifications that could be made, but the authors are reviewing whether these are really needed. Authors will send a note to the IPsec WG list if the is a decision to update with these clarifications. There is a clarification email that is ready to be sent to the WG list to describe implementation techniques possible for multiple clients behind the same NAT going to the same destination. This was distributed on July 18th. There are a number of independent implementations of draft-02: SSH, Cisco, Microsoft at least. There were approximately 8 to 10 vendors total testing some part of an implementation last August with draft-01 UDP500. Interop Testing Draft-02 versions with UDP4500 have not been covered by a bakeoff. The bakeoff last August covered draft-01 that didn't use UDP4500 encapsulation. Vendors should be testing with each other. There is one IPR question that only implementers can answer. The answer should be reflected in their comments on the list, to WG chairs, ADs or IESG during this Last Call period: Whether SSH's IPR terms are too broad to be considered OK by the WG for a standards track RFC since it allegedly purports to cover technology that is mandatory to implement. This question comes up as a result of the recent (last 3 months) SAAG discussion (on SRP) on what IPR constraints are acceptable for technology that covers mandatory to implement features of IETF drafts. The concern is that the non-assert limitation is too broad, in that it covers all other IETF IP. The URL for IRP/SSH-NAT can be found at: http://www.ietf.org/ietf/IPR/SSH-NAT IPsec and mobile Ipv6 - Francis Dupont: draft-pdupont-ipsec-mipv6-01.txt Francis provided a quick summary on the status of his draft. One basic idea was to remove the "versus". The draft provides many small implementation choices. It seeks to remove double encapsulated (i.e. no tunnel in a tunnel) tunnels. The ultimate target: an endpoint address update exchange in SOI (next version of IKE). IKEv2 and mobile IPv6 Sec 2.11 address and port agility: IKE implicitly sets up ESP, AH and IPCOMP associations for the same IP address it runs over. Proposal; add an option to protect the transport address when NAT traversal is not wanted or required. Proposal; use only the SPI (i.e. cookies) to select the proper ISAKMP/IKE SA. A peer may change its transport address between "phase 2 exchanges. Proposal; add an optional return-routability check when a peer changes its transport address Proposal; add a new transport address update exchange to avoid the current mandatory and expensive rekeying. Steve Kent raised the following question. Francis mentioned a security flaw in relation to the tunnel over tunnel encapsulation scenario but the problem was not clearly articulated. It was offered as an observation by Steve Kent that the problem is not with the outer wrapper. Francis replies that it was an issue with traffic routing, not so much a security flaw per se but it may still lead to a DoS. Does this attack require a Man in the Middle Steve. Kent asks? WG Chair, Barbara Fraser, asks where is the threat draft. Francis says he will send this issue to the list for advisement. Next question from the floor: Jari Arkio asks, "Does this require code change in IPsec and/or IPv6? Francis Dupont replies that it is minimal in IPv6 but may have more changes in IPsec. Jari seeks further clarification: "in order to interoperate with IPv6 mobile node and the user wants to employ IPsec and the other node is IPv4, is there an interoperability problem? This issue wasn't resolved. Latest AH Draft - Steve Kent Continuation of revisions for AH and ESP. Revisions posted but received very few comments over the month. However, Steve did try to reflect changes in his briefing. There will be an IPsec DOI addendum for ESP option as requested by the WG co-chairs. Multicast and IPsec Multicast issue: Clarify SA identification, terminology change (authen->integrity). Change 64 bit sequence numbers. Identifying a multicast SA: A multicast SA was previously identified by destination IP address and SPI that assumed a single controller for a given multicast group. Suggestion was made to identify multicast SA by source address, to accommodate SSM. Later comments from the list suggest that both addresses plus SPI are needed to demux multicast SAs. Observation offered; where contradictory direction exist, Steve said he needs precise clarifications of what is needed for demuxing. Vendors are starting to put up requirement of speed for demux. Anti-reply For single multicast sender there is no issue. However, with multi-sender SAs is different. . Suggestions that receivers maintain a separate window for every sender would not scale well nor would there be many vendors willing to go down that complicated path. Therefore, the group will have to decide how to handle multi-sender SAs or just say no to the use of anti-replay. There were no questions for Steve. He did stress again that the WG needs to decide on some of the issues before the drafts can advance. SOI Discussion Summary - Charles Kaufman Charlie was "volunteered" to summarize the comments from the WG mailing list as related to the SOI requirements. The requirements for the next version of IKE have been sent to the list over the last several weeks by the WG co-chairs. This exercise was instituted to obtain a sense of what features the members would like to see in the next version. Charlie's opening observation was that as he examined the results from the mailing list closely, the overall consensuses leaned towards those requirements that are already articulated in the draft known as IKEv2. Charlie is one of the co-authors of that draft and is well versed on the details contained in that draft. For each of the requirement/feature questions sent out to the membership Charlie summarized those points. (See Charlie's slides) Angelos Keromytis made a clarifying point in regards to establishing an SA. The JFK draft states that under its SA establishment scenario, 4 messages are always used for this purpose. Angelos is a co-author of the JFK draft. Steve Bellovin, Security Area Director, strongly commented that any drafts that contained specific vendor extensions would cause the IESG to be concerned and may even cause it to be rejected. He states this in his capacity of Area Director, not as a co-author of the JFK draft. Greg Lebovitz asked Charlie. Kaufman whether NAT-T capabilities would be added to the drafts. Charlie replied that there is a plan to add it. However, both drafts as now written meet the requirements of the NAT- T specifications. Upon conclusion of the SOI summary, the Chair presented a timeline and plan for bringing the selection of the next version of IKE to a close with a definitive decision being made at or before the November IETF meeting in Atlanta. Those timelines are shown below. Aug 30: closure on SOI features Sept 30: SOI ID completed Oct 1-25: discussion on list Nov 4: updated ID Nov 18-22: Atlanta IETF meeting After the timeline was presented, the Chair opened the floor for discussion. Open Microphone Session Clearly, the most pressing concern of those gathered in the IPsec WG meeting was the SOI debate. The open microphone session lasted about 45 minutes and was exclusively related to SOI. Although the points of each opinioned varied, the common thread was that this process of selecting the next version had gone on long enough and that the membership wanted a selection to be made. There were comments that suggested enough work had been done on the drafts and that once the authors incorporate the changes derived from member comments regarding desired features, it was time for the co-chairs to make a decision. The suggestion that there could in fact be 2 SOIs was rejected as being too confusing to the outside Internet community and that only one draft should be approved even if that meant some form of merge or cooperation between the two draft teams. Jeff Schiller, Security Area Director, reinforced the concept of closure by indicating that he would make a decision if the WG were unable to decide by itself. The Chair indicated that closure would happen according to the timeline and plan announced earlier in the meeting. There being no further discussion, the meeting was adjourned.
- draft minutes from wg meeting Barbara Fraser