draft minutes from wg meeting

[Barbara Fraser <byfraser@cisco.com>]

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.