IETF 66, 2006-07-10
The base specification document set was considered by the Working Group and there are considerations of IPR and the interaction between Shim6 and IPSEC that require some further effort at achieving WG consensus prior to undertaking a WG Last call on these documents.
The Working Group reviewed progress with implementations of this protocol.
The WG considered areas of potential extension of this protocol, as well as the overall direction of the work in this working group.
WG is still on the progress of making the base documents as Proposed Standard on the basis that we can resolve remaining issues to the WG's satisfaction.
Proposed adoption of new WG documents. Applicability statement and API document
Last call of HBA / Proto / Failure Detection document set
Applicability draft
Locator Pair Selection draft
Ingress Filtering
Extended Shim6 Design
Privacy Analysis
Socket API
1) Administrivia
2) Status of "base specification" document set
Level 3 multi-homing shim protocol
draft-ietf-shim6-proto-05.txt
Hash Based Addresses (HBA)
draft-ietf-shim6-hba-01.txt
Failure Detection and Locator Pair Exploration Protocol for IPv6
multi-homing
draft-ietf-shim6-failure-detection-05.txt
3) SHIM6 Applicability
Applicability (Marcelo Bagnulo, Joe Abley)
draft-ietf-shim6-applicability-01.txt
4) SHIM6 Implementation Reports
Implementation Report (Marcelo Bagnulo)
Progress report on ETRI SHIM6 Implementation (Taewan You)
5) SHIM6 Extension Drafts
Locator Pair Selection (Marcelo Bagnulo
http://draft-ietf-shim6-locator-pair-selection.potaroo.net">draft-ietf-shim6-locator-pair-selection-00.txt
ESD (Erik Nordmark)
http://draft-nordmark-shim6-esd.potaroo.net">draft-nordmark-shim6-esd-00.txt
. Ingress Filtering (Marcelo Bagnulo)
http://draft-bagnulo-shim6-ingress-filtering.potaroo.net">draft-bagnulo-shim6-ingress-filtering-00.txt
Privacy Analysis (Marcelo Bagnulo)
http://draft-bagnulo-shim6-privacy.potaroo.net">draft-bagnulo-shim6-privacy-00.txt
Socket API (Shinta Sugimoto)
http://draft-sugimoto-multihome-shim-api.potaroo.net">draft-sugimoto-multihome-shim-api-00.txt
6) WG Direction
WG Direction (Illjitsch van Beijnum)
[no presentation slides]
The WG chair's report noted that Hash Based Address draft has passed a WG Last Call in October 2005, the Protocol Specification has passed a WG Last Call early 2006, and the Failure Detection and Locator Pair Exploration has not been Last Called as yet.
The WG chairs noted that the ADs have requested that the base protocol specification documents be reviewed by the IESG as a set, and it made sense to perform a Working Group Last Call for the set of these three documents.
The chairs proposed a Working Group Last Call on these three documents, if there is no objection. The chairs asked for comments on these 3 base specification documents.
[WG Comments on the Protocol Specification Document Set]
Jim Bound: I intend to await the IETF Last Call, but at that stage I will object to these documents on the basis of considerations of IPR and the interaction of this protocol with IPSEC. These are serious and unacceptable problems. I see no further value in discussing this in the WG, and would prefer to outline my case to the IESG.
Chair (Geoff Huston): For the benefit of WG members could you elaborate on your issues with IPR?
Jim: CGA - Ericsson's IPR statement is not acceptable. It says that Ericsson will interfere with your right to use these, unless the user imposes a patent condition on Ericsson. This is not acceptable. HBA is based on CGAs. I want to make this an IETF issue and that's why I prefer to raise this at IETF Last Call time.
Chair (Geoff Huston): Ask the WG for some guidance here as to what to do. We have consulted with the ADs on this topic, and we've been advised that the ADs will follow the WG's advice and guidance here. Is there further comment on the IPR issues on the use of cryptographic material in the identity part of the address as it pertains to HBA use in SHIM6, now would be a good time to say so, as the WG view is one that the IESG will note. I would like to hear other views on this.
Jim: This is a much bigger issue than shim6. I would like to use this as grounds for an appeal to amend the way in which we operate in the IEF. This is unacceptable and we cannot go on like this in the IETF. I would hope that the Shim6 Working Group proceeds with these document as I would prefer that this issue was raised at the IESG level.
Kurtis: Noted that this is not an unique IPR condition, and similar IPR constraints are in other parts of IETF work.
Jim: So this is not an issue that is unique to this WG.
Jim: The IPSEC issue is that the ULIDS should be encrypted by IPSEC. I'm going to object to this.
Chair (Geoff Huston): Could we divide the two issues and collect IPR issues first.
Jari Arkko: AS a process comment, it's WG's responsibility to decide based on various factors (technical, IPR, etc.) with regard to the documents. WGLC would be a good place for WG members to give opinions. When it comes to IETF LC, it's also IETF issue not just a WG issue. The WG members should voice their preferences at Working Group Last Call time.
Illjitsch van Beijnum: Does Ericsson's IPR cover also HBA not only CGA?
Jari Arkko: [author and Ericsson employee] The intent of the IPR declaration is to make if possible to use the public key versions without problems and it does not intend to collect money from companies. The constraints are defensive in nature. I am personally not sure if the patent covers HBA or not. The IPR claim states that it may apply.
Illjitsch van Beijnum: This point is important. We should know this in advance. If the CGAs are the problem, then we could change HBAs not to be dependent on HBAs
Kurtis: But to establish this may entail some form of legal action
Illjitsch: Is there someone who could advise us here?
Kurtis: That's not the way IPR works.
Bob Hinden: I think this is general IETF issue. This type of IPR statement is fairly common. My suggestion to Jim is that appeals will not produce what you are looking for. This form of IPR is allowed with the current process documents. You may want to consider a BOF and then chartering a WG to examine this issue in detail.
Dave Thaler: There is an IPR WG already meeting this week.
Jim Bound: SeND is also based on CGA. Think that IPsec works fine for SeND. Its good that there is an IPR WG in the IETF, but I still intend to appeal this on IPR grounds.
Suresh Krishnan: The IPR is Non Assert (NA) just for the SEND specification, and seems not to apply to HBA implementations.
Hannes Tschofenig: We should be careful about the coverage of the IPR as in many cases it's not clear. It's not good for WG to solve legal issue.
Chair (Geoff Huston): Chairs are not expecting WG to solve legal issue. But the ADs would like to sense the level of comfort of the WG members to pass the documents to the IESG for RFC publication.
Pekka Savola: This is a more generic issue. We had similar situation with Cisco in the NEMO WG.
John Loughney: I would be more comfortable if this (HBA) is not the key part of the protocol. For SHIM6 to be successful, we need to see a lot of open source implementations, and this IPR may inhibit open source projects to implement the specification. My comfort level would be higher without the IPR.
Chair (Geoff Huston): HBA is one of the core documents. HBA is certainly part of specification.
Speaker (the person who submitted the IPR statement from Ericsson): Discussions made so far only cover one side. Those who feel uncomfortable with Non Assertion, free-of-charge statement, can actually take a license and sue if they want. There are two options, not one.
Vijay Devarapalli: Think RAND (Reasonable And Non-Discrimatory terms) is good enough and Ericsson's IPR claim does give you RAND. It would be good if royalty free to open source implementations were available and give RAND for any other companies. This has been used for other protocols in the IETF.
Jari Arkko: Yes, Ericsson's IPR statement actually provides this. Anyone can use this technology free as far as we (Ericsson) are concerned. And RAND condition can also be applied.
Jim Bound: As a Working Group member I object to this. People representing company and dealing with IPRs make IETF more complicated. We should stop this. People should attend IETF as individuals. If you are presenting corporate work that has patents, then this should not be part of the IETF. I do want patented technology to be in the IETF. we should stop this.
Marcelo Bagnulo: I am author of the HBA document and I don't work for any company and I didn't come here with any kind of patents.
Illjitsch van Beijnum: Maybe we would be more comfortable is we had an alternative to HBA. For proxy, HBA is hard to do.
Chair (Geoff Huston): I'm asking for a show of hands: based on the spec we have now and the IPR knowledge we have now, then I'm asking as chair for a show of hands on the level of comfort and the level of discomfort in proceeding to a Working Group Last Call on these documents.
*** Voting ***
Asking WG members for comfort level to the base documents as it is now. Not for making a Working Group decision but for feeling the sense of the WG members
Results of the straw poll:
Summary:
***
Chair (Geoff Huston): As in current SHIM6 architecture, IPsec is based on ULID, not on locator. But Jim Bound suggested that the order of ULID substitution and IPsec processing should be reversed. Any comments on this? [no further WG comment] Jim, could you explain the reasons for your position?
Jim Bound: IPSEC architecture takes addresses based on the addresses in the packet. Jim asserts that the IPSEC in shim6 needs to take the addresses that are nested within the packet, and not the outer packet header addresses. Does not know how decrypt IPsec protected packet can be done. In the current IPsec model, decryption is done based on the IP address not by locator.
Dave Thaler: (for inbound packet processing) Demux of SHIM6 header will be done based on context ID. All that appears in the data packet is the context identifier. This context identifier then allows ULID substitution into the packet header.Then IPsec processing is done based on ULID pair.
Jim Bound: In the past decision was made not to do out-of-band signaling. We chose not to do this out-of-band signaling some years back. IN shim6 we are reversing the architecture decision.
Dave Thaler: The issue you (Jim Bound) is raising is in-band signaling vs. out-of-band signaling ?
Jim Bound: Yes. It has an affect on implementation.
Illjitsch van Beijnum: But you can see in the packet the IPsec header first or SHIM6 header first, in either case, one should coordinate to the other end.
Chair (Geoff Huston): Please write down concerns on this topic and post them to the mailing list.
Pekka Savola: Clarification on HBA. What was the results of security directorate?
Jari Arkko: Feedback from security directorate: Seems to work. Concern about relation with other existing mechanisms like CGA. Also what about implications using HBA together with IPsec based on public key. What would that mean? No conclusion made on what exactly we should do made by the WG.
Summary by the chairs:
SHIM6 Applicability (Joe Abley)
Vijay Devarapalli: One objection to the use of SHIM6 for route optimization in MIP6. Prefer using SHIM6 for MIPv6 node which has multihomed home network.
Marcelo Bagnulo: Ok with removing it (route optimization based on SHIM6).
Shinta Sugimoto: Just want to mention that socket API that we define also touches some interactions between SHIM and upper layer protocols, namely application.
Joe Abley: It's for application. But what specifically mentioned in the presentation is about interaction between shim and transport layer protocol.
Chris Wood: Why SHIM6 is doing this at host-level, not by network-level?
Chair (Geoff Huston): In the past activity on multi-homing and IPv6 was done in the Multi6 WG. This work terminated in the last August with a recommendation to IESG to proceed with a protocol, which is a SHIM6. The WG is chartered to develop the protocol for particular architecture.
SHIM6 Implementation Reports
Implementation reports (Marcelo Bagnulo)
Ericsson - based on HIP4BSD, timeframe is 2006.
UCL - already have an alpha version. September 2006.
OpenHIP - planning to work on SHIM6. GPL.
ETRI - Progress Report on Shim6 Implementation (Taewan You)
Working on development of SHIM6 implementation on Linux.
Phase-1:
Phase-2:
Default locator-pair selection algorithm (Marcelo Bagnulo)
How to select locator pair after the outage. Why not 3484? Need to consider additional preference information is provided by SHIM6 protocol itself.
Jari Arkko: High level comment about the rule set. What is your plan to proceed these rules? Incorporate them into reachability protocol?
Marcelo Bagnulo: I have no plan.
Jari Arkko: It may be better to incorporate them later, after issues are solved. There are a number of rules and some open issues are still there. This appears to be future work for Shim6.
Tim Shepherd: There is potential for considerable complexity here. Did you include site administrator's preferences? For instance, campus network. When should this decision (preference on locator) should be made? This is an interesting issue. Also the locator choice has path implications. Should path characteristics have an impact on locator selection rules? Is trying to make the right thing happen in scope for this working group?
Chair (Geoff Huston): yes
Marcelo Bagnulo: Draft takes into account for local priority/weight, local pair preference table. How to distribute the priority (preference) is outside scope. Dynamic adaptation based on a kind of measurement would be hard to do. Protocol is needed to perform the measurement.
Illjitsch van Beijnum: There is the option of inclusion of timestamp information in the packet for measuring RTT. The trouble is that it would become necessary to perform measurement experiments for all available combinations of locators.
Tim Shepherd: If the task is to download a large object, then there is some real value in selection of a high volume path. Is this in scope for the working group?
Geoff Huston: (not chair) The base spec has made a number of simplifying assumptions to get a working model specified, and part of that assumption set is that all applications are the same and all locators are equivalent in terms of their properties. However, its recognized that different applications have different desires for underlying path characteristics. Context forking allows application to specify locator preference. Richer API may allow application to allow "fork" the context and gather more information about the path and greater levels of preference setting by the upper protocol entity. For example VOIP may have different desires than bulk transfer.
Tim Shepherd: This is a reassuring response.
Geoff Huston: Shim6 gives you a set of abilities in terms of forked contexts.
John Loughney: Good potential for unbounded problem space. There are lots of factors (bandwidth, RTT, price etc.) to consider in terms of making choice of locator.
Dave Thaler: What's the relation with this work to the RFC3484 update? In SHIM6, application basically does not know if there is shim or not. API may be required for application to make the initial selection but what's the difference? How much of them can be common? Does it make sense to combine them?
Marcelo Bagnulo: This draft specifies rules that takes into account for the information provided by the SHIM6 protocol itself. This is not the case in normal(non-shim6) case which is discussed in RFC3484. Secondly, some of the choices are not exactly the same for identifier selection and locator selection.
Not sure if we want to add complexity which results from locator information into RFC3484 update.
RFC3484 refinement is treated in INTAREA.
Illjitsch van Beijnum: Think it's good to separate the two documents. In locator-pair selection, we focus on reachability. On the other hand, in RFC3484 you assume everything works.
Dave Thaler: Maybe information from locator-pair selection algorithm may be useful for normal source and destination address selection (RFC3484).
Illjitsch van Beijnum: Actually there are other things that can also be used too. TCP knows reachability of the two endpoints. SCTP too.
Dave Thaler: NUD in IPv6 takes account for information from upper layer protocol to determine reachability. Abstract API can be used to handle this information.
Greg Daley: Existing document which describes protocol independent transmission control block. Can also be used to figure out reachability to the destination.
Summary by Chair:
Ingress Filtering and Exit Path Selection (Marcelo Bagnulo)
[presentation]
Chair (Geoff Huston): If there is no objection, the WG will take this document as WG item.
[no objection and the document was proposed to be adopted as a WG document]
Socket API for multi-homing Shim (Shinta Sugimoto)
[presentation]
Francis Dupont: See common issue with mobility case. This kind of extensions are not necessary for all application. So, the effect should be limited to the application that requests it.
Shim6 WG direction (Illjitsch van Beijnum)
[presentation]
Kurt Lindqvist: (not as chair) I disagree with the suggestion here about going for experimental track documents in preference to standards track. If there is any feature that should be included in the spec and must work from the first day for shim6 to work, then those should be included in the specification. This is the purpose of a last call. If there are additional features required ion the base spec then list them for the working group and allow the working group to consider them. This has been the way we've operated in shim6 to date.
Jari Arkko: The threads that you (Illjitsch) mentioned on the mailing list are valid but I disagree with adding new features to the protocol at this stage. Would rather do these as extensions, and move forward the current spec, without making a big initial spec.
Marcelo Bagnulo: My main concern with additional stuff is complexity. Base spec is already big at 150 pages of documentation. Adding to the specification should be only on the condition that its really necessary.
Bob Hinden: I disagree with the suggestion Illjitsch is making. Think that WG should go full speed ahead. Get the standard and deployment. Don't spend time spinning.
Illjitsch van Beijnum: refer to the M&O bits in IPv6. Not proposing to take 2-3 more years or making the spec twice as big as it is, but providing right features would save time in the end.
Jari Arkko: Spending more time on specification does not imply that the specification is any better. What is needed now is some feedback from implementations.
Pekka Savola: We should be happy with applicability statement when we ship the spec.