[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Shim6 Meeting at IETF 67 - Minutes
Thanks to Olaf for taking the minutes, and Wouter for the Jabber log and Brian for the additional notes!
Attached is the draft of the minutes - unless there are comments and/or corrections we'll run with this
regards,
Geoff & Kurtis
---------------------
SHIM6 MINUTES
Meeting : IETF67 Nov 9, 2006
Location: Grand Ballroom AB, 13:00
Chairs : Geoff Huston
Kurtis Linqvist
Minutes : Olaf Kolkman (olaf@nlnetlabs.nl)
(substantive input from Brian Carpenter)
=========================================================
AGENDA:
1) Administrivia 5 minutes
- Mailing list: http://ops.ietf.org/lists/shim6/
- Scribe?
- Blue Sheets
- Agenda Bashing
2) Last Call Review of "base specification" document set 75 minutes
1. Level 3 multi-homing shim protocol
draft-ietf-shim6-proto-06.txt
2. Hash Based Addresses (HBA)
draft-ietf-shim6-hba-02.txt
3. Failure Detection and Locator Pair Exploration Protocol for IPv6
draft-ietf-shim6-failure-detection-06.txt
3) Shim6 API Draft Update 10 minutes
draft-ietf-shim6-multihome-shim-api-00.txt
4) Update on Applicability & Locator Pair Selection drafts 10 minutes
draft-ietf-shim6-applicability-02.txt
draft-ietf-shim6-locator-pair-selection-01.txt
5) Final Report for SHIM Implementation. 15 minutes
6) WG Direction 5 minutes
==========================================================
SUMMARY:
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.
==========================================================
NOTES:
1) Meeting Administrivia
Nobody volunteered as scribe (Olaf Kolkman did it anyway).
Wouter Wijngaards volunteered as jabber scribe.
Agenda accepted as is.
2) Last Call Review of "base specification" document set
=== Documents:
1. Level 3 multi-homing shim protocol
http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-06.txt
2. Hash Based Addresses (HBA)
http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-02.txt
3. Failure Detection and Locator Pair Exploration Protocol for IPv6
multi-homing
http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-06.txt
Slides: http://www3.ietf.org/proceedings/06nov/slides/shim6-1.pdf
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.
Marcello 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:
"This does not preclude using IPSEC tunnels on SHIM6 packets
within the network transit path."
- 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:
1. More detail in the behavior section, Jari requests for feedback
on the text on-list
2. Drawing the state machine using a different representation. That
has been suggested previously, and rejected, because the number
of states would be much bigger and therefore the state machine
description would be less clear than now.
3. There is a timeout of 10 seconds, unilateral, an option may be
good instead of a fixed value. Jari requests for feedback.
** Tom Henderson suggested to make textual clarifications of the state
machine and offered to provide text on an option to negotiate
timeout.
3) 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.
4) 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.
5) 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.
Plan a policy component too, and API.
No discussion.
6) 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.