Notes from the IETF 66 WG Meeting

[Geoff Huston <[e-mail]>]

Site multi-homing by IPv6 Intermediation WG (SHIM6)
IETF 66, 2006-07-10 15:20


CHAIRS:

   Geoff Huston & Kurtis Lindqvist

NOTES:

   Shinta Sugimoto

SUMMARY:

   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

ACTIONS:

   Last call of HBA / Proto / Failure Detection document set

     - IPR issues with HBA and CGA use in Shim6

     - IPSEC and ULID issues

     - Re circulate Security Directorate review of SHim6

   Applicability draft

     - Revise draft per WG comments

   Locator Pair Selection draft

     - Revise draft per WG comments
     - KJeep this separate from  draft-bagnulo-rfc3484-update-00.txt

   Ingress Filtering

     - Adopt draft-bagnulo-shim6-ingress-filtering-00.txt as a WG document?

   Extended Shim6 Design

     - Adopt draft-nordmark-shim6-esd-00.txt as a WG document?

   Privacy Analysis

     - Adopt draft-bagnulo-shim6-privacy-00.txt as a WG document?

   Socket API

     - Adopt draft-sugimoto-multihome-shim-api-00.txt as a WG document?

AGENDA:

  1) Administrivia

    - Mailing list: http://ops.ietf.org/lists/shim6/
    - Scribe?
    - Blue Sheets
    - Agenda Bashing

  2) Status of "base specification" document set

     1. Level 3 multi-homing shim protocol
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt

     2. Hash Based Addresses (HBA)
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt

     3. Failure Detection and Locator Pair Exploration Protocol for IPv6
        multi-homing
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-05


  3) SHIM6 Applicability


     1. Applicability (Marcelo Bagnulo, Joe Abley)

        Applicability Statement for the Level 3 multi-homing Shim Protocol
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-applicability-01.txt


   4) SHIM6 Implementation Reports


      1. Implementation Report (Marcelo Bagnulo)

      2. Progress report on ETRI SHIM6 Implementation (Taewan You)


   5) SHIM6 Extension Drafts


      1. Locator Pair Selection (Marcelo Bagnulo)

         Default Locator-pair selection algorithm for the SHIM6 protocol
         http://www.ietf.org/internet-drafts/draft-ietf-shim6-locator-pair-selection-00.txt

      2. ESD (Erik Nordmark)

         Extended Shim6 Design for ID/loc split and Traffic Engineering
         http://www.ietf.org/internet-drafts/draft-nordmark-shim6-esd-00.txt


      3. Ingress Filtering (Marcelo Bagnulo)

         Ingress filtering compatibility for IPv6 multihomed sites
         http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-ingress-filtering-00.txt


      4. Privacy Analysis (Marcelo Bagnulo)

         Privacy Analysis for the SHIM6 protocol
         http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-privacy-00.txt


      5. Socket API (Shinta Sugimoto)

         Socket Application Program Interface (API) for multi-homing Shim
         http://www.ietf.org/internet-drafts/draft-sugimoto-multihome-shim-api-00.txt

  6) WG Direction

      Illjitsch van Beijnum

NOTES:

  - Status of "base specification" document set (Chairs)

    [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 actually 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:

        Comfortable: 18
        Not Comfortable: 20

    Summary:

    No consensus. WG will not going to the WGLC for the base 
documents. Need to solve these issue with IPR to the WG's satisfaction.

    ***

    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:

    WG will not go for WGLC. Following issues need to be solved:

        1) IPR issue (CGA and HBA)
        2) IPsec and ULID
        3) Consideration of security review of HBA



  - 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:
        - SHIM6 stack based on Netfilter
        - Library for SHIM6
        - Simplified testbed
      Phase-2:
        - Direct kernel patch for SHIM6
        - API for cross layer
        - Extended socket API for SHIM

  - 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:

      - Locator-pair document will be worked in SHIM6 WG and RFC3484bis to
        be worked in INTAREA. (no objection was made)


  - 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.