9 Nov 2006, 1300 - 5000
Geoff Huston & Kurtis Lindqvist
Olaf Kolkman (olaf@nlnetlabs.nl)
(substantive input from Brian Carpenter)
Administrivia
WG Last Call Review of "base specification" document set -- 75 minutes
Shim6 API Draft Update -- 10 minutes
Shinta Sugimoto
Update on Applicability & Locator Pair Selection drafts -- 10 minutes
Marcelo Bagnulo
Final Report for SHIM Implementation. -- 15 minutes
Kunwoo Park
WG Direction -- 5 minutes
The WG agenda items covered the WG Last Call on the base protocol specification documents, and reviewed progress with related drafts, as well as the status of an implementation of SHIM6.
Some further minor modifications were proposed to the protocol specification and failure detection documents, but no other issues were raised in the meeting. The chairs are confident that this will allow for a consensus call on advancing these documents as Proposed Standards to the IESG.
There are a number of implementation efforts underway.
The chairs proposed that the WG not meet at IETF 68, and decide on IETF 69 at a later date, and allow some time for experience to be gathered with the base specification before moving on to considering any form of extensions to the protocol.
Meeting Administrivia
Nobody volunteered as scribe (Olaf Kolkman did it anyway).
Wouter Wijngaards volunteered as jabber scribe.
Agenda accepted as is.
Last Call Review of "base specification" document set
Documents:
Co-Chair Geoff Huston pointed out that there is not sufficient indication for him and co-chair Kurtis Lindqvist to push the 3 core documents to the IESG for draft standard. More feedback is needed.
Huston went into a mini-tutorial of the architecture and backgrounds. After that Marcello Bagnulo went over the issues that came up during last call.
SHIM6 HBA issues
IPR issues.
Are the Ericsson statements acceptable for the WG?
Chair asked for last-call feedback: Nobody had issues.
IANA considerations
Any problems to use CGA extensions registry as defined in RFC4581?
Chair asked for last-call feedback: Nobody had issues.
Security Considerations
Are there any residual security considerations ?
Carpenter brought up the reference to another draft (multiple-hash-cga). It is not clear if this is a normative reference.
Jari Arkko argued that SHA1 dependency issue is general. It does not need to be resolved here.
There was not objection to this not being considered as a normative dependency.
Jim Bound stated that all his issues have been resolved. He gave the advice that the drafts be published as Proposed Standards, and warns that people are not buying into this.
Via jabber, Iljitsch van Beijnum asked if the work be held off to see what happens with respect to the routing and addressing workshop?
Several people respond that the existing efforts should continue while the work on the bigger issues also continues. Besides, there are several interest groups, the folk that will need to make SHIM6 happen are the implementors of TCP stacks. And this work may provide context to other groups.
SHIM6 Protocol issues
Marcelo continues to describe the issues with the proto draft.
The interaction with IPsec bump in the wire (BITW)
Implementing part of shim6 in BITW is the obvious way forward. The alternative is to layer shim6 above IPSec? But then there would need to be an SA for each locator pair. This still doesn't protect shim6 itself. And it's complicated, so no work proposed on this.
Via jabber, Iljitsch van Beijnum commented that it did not appear feasible to support disconnected SHIM6 in BITW.
Chair asked for last-call feedback with providing the advice that BITW implementations of IPSEC also needed to support SHIM6: Nobody had issues.
** Brian Carpenter proposed to add the following text to the proto document:
Provide SHIM 6 security based on IPSec SAs
Could we layer shim6 above IPSec? But then there would need to be an SA for each locator pair. One approach proposed was to support the SA with certificates with ULIDs, and the consequent issues relating to certificate issuance and revocation. The second option is to use pre-existing IPSec trust relationships, which is in effect Mobile IKE. No work proposed on this.
Chair asked for last-call feedback: Nobody had issues with this proposal.
ULID security mechanism
Based on WG mailing list comments, the question was posed as to whether there should there be an alternative to the HBA method, and should the binding security be more modular?
Chair asked for last-call feedback: Nobody had issues with the proposition that we already have sufficient ULID security mechanisms.
On DOS attacks on exhausting the context tags
4-way handshake will create state, but TCP does that as well and this is equivalent, so this is no worse than TCP.
Chair asked for last-call feedback: There was no consensus for change.
Allow forking
Context forking has been there for applications to request different contexts for different circumstances. The issue is addressed sufficiently according to Dave Meyer (the reviewer who raised this issue).
Use of ULID after prefix renumbering
The security properties are being explained and Huston, Carpenter and Bound support the proposal that once the site is renumbered, the context is destroyed. It should be clear that after the old prefix is removed the context is destroyed.
** There was consensus to include in the document that once a prefix is withdrawn that any further use in SHIM6 as a ULID should not be supported, and that the associated context states should be withdrawn.
Do we need a minimum CGA key length specified?
Huston argues to use normative references to the CGA specs.
Jari argues that this document only specifies the minimum length.
** Jari suggests to take the value from the SEND spec. There was support to make this modification to the document
Definition of Broken flag.
This has been addressed.
Chair asked for last-call feedback: Nobody had issues with this text.
SHIM6 Failure Detection draft
[No slides.]
Jari noted that he had 3 items to mention:
** Tom Henderson suggested to make textual clarifications of the state machine and offered to provide text on an option to negotiate timeout.
Shim6 API Draft Update
Shinta Sugimoto
This API Allows upper layer to have better control of Locator management, failure detection and path exploration. It covers requirements but needs further work on solution aspects. This version defines data structures and various read and write operations, and cleans up the socket options defines.
David Thaler and Erik Nordmark had a discussion on ancillary data, sessions, contexts and their interaction. One suggestion is that if sockets use different options, the one forks the shim6 context.
Chair suggests to send carefully crafted words on this topic to the working group.
Update on Applicability & Locator Pair Selection drafts
Marcelo Bagnulo
On shim6-applicability
Brian Carpenter commented that SHIM6 may work for a small client but for a big server the CPU might melt; The document could address the considerations for the different usage scenarios and what the effect on the amount of state is. Huston suggests that Nordmark supplies text. Nordmark refers to multi6 work for what the effect on applications is. Huston reminds himself that he has an action to dig up text.
Jim Bound suggests a description of several use cases to push deployment.
On shim6-locator-pair selection
Dave Thaler argues that RFC3484 provides a number of constraints and asks what the goal of this document is. This document integrates SHIM6 into the RFC 3484 framework.
Final Report for SHIM Implementation
Kunwoo Park, SNU
The project does not have a web page yet. The project completed a shim6 core daemon and REAP on simple testbed all based on the -05 drafts. Platform is Linux 2.6 or higher. The daemon is in user space as a callback from the IP stack. See slides for features included. (Clarification for slides: Implementation features in blue are done, in black are not) (No security yet.) Phase 2 will have shim6 integrated in stack.
This project is planing a policy component too, and API.
No discussion.
Next steps
Assuming consensus on Working Group Last Call, the chairs will ship off the documents to the IESG and propose that the working group will not meet at IETF 68, and maybe meet at IETF 69. In that time people can get experience with the base shim6 specification and implementations, and these experiences can be collected.
The Chair noted that there are four implementation efforts underway with the SHIM6 protocol.