SHIM6 WG meeting notes from IETF 63

[Geoff Huston <[e-mail]>]

This is the draft of the notes of the SHIM6 meeting at IETF 63.

Thanks to Spencer for preparing these notes.

Are there any comments on these notes as a record of our meeting?

Thanks,

    Kurtis & Geoff

-------------------------------------------------------------------------


Site multi-homing by IPv6 Intermediation WG (shim6)

Tuesday, August 2 at 0900-1000
Wednesday, August 3 at 0900-1000
================================

CHAIRS: Geoff Huston <[e-mail]>
         Kurtis Lindqvist <[e-mail]>

Notes: Spencer Dawkins <[e-mail]>


SUMMARY

   Initial WG meeting. There are five areas of design activity namely
   protocol, triggers, crypto-locator use, architecture and applicability.
   Initial drafts in these areas are based on the concluding design team
   work in the Multi6 Working Group

   The current status on each of these areas was presented to the Working
   Group for review.

   Next steps will be based on further refinement of five working group
   documents, using lead authors / editors assigned to each draft.

ACTIONS

   * Pekka Nikkander, John Loughney and Christian Huitema
     to prepare some initial ideas (slide pack / draft) on a bi-directional
     SHIM / ULP API that would include the ability for the ULP to
     obtain/share locator pair path info and then express a locator pair
     preference to the SHIM (i.e. keep the notion of binding sessions at the
     transport level but allow ULP signaling to include Loc Pair
     preferences to be expressed) in addition to sending the SHIM the
     trigger / heartbeat information associated with the current locator
     pair.


NOTES

1. Agenda Bashing

    - A very tight agenda.
    - no changes proposed.
    - Noted that the SHIM6 Charter discussion has already happened...

2. Review of status and proposed work areas

    Overview
       Kurtis Lindqvist

    MULTI6 drafts moving to SHIM6 (with very few changes).

      - Charter is very aggressive.

      - A lot of questions are going to pop up as we work on a protocol,
        including consideration of state management, identifier
        characteristics, locator pair detection, etc.

    Architecture
      document: draft-ietf-shim6-arch-00.txt
      Geoff Huston

      - MULTI6 architecture draft is in RFC Editor Queue now, this is trying
        to be a taxonomy as well (what layer, where identifiers are
        rewritten, etc.)

      - Includes a discussion of identities (ephemeral, persistent, etc.)
        and implications.

      - Includes a list of things that need to happen in a protocol that
        does SHIM6 - how do you set up session state? how do you know to
        re-home? what is Identity Equivalence? How do you select locators?
        How do you remove state?

          Aaron Falk: is this restoration and repair, or multi-homing? Open
          question, but this is unicast, not multicast, so assuming
          alternate paths are idle at session layer.

          Jason Shiller: has to take into account more than just restoration
          and repair - we can do load balancing in IPv4 today, for example.
          Need to get the basics right first, though. There is discussion
          about traffic engineering, but we'll need to do more.

      - Initial draft, is incomplete - add equivalent state and design
        tradeoffs, at a minimum.

      - SHIM6 is in IP layer, and is actually below things like
        fragmentation/reassembly, AH/ESP, etc.

      - SHIM6 uses "the first" locator as the identifier, but can map other
        locators to the same identifier - identifiers should be referable.

      - Need more text on maintaining state in this draft. At IP level, we
        don't have all the information that would be available at transport
        or at application levels.

      - Routing information isn't in hosts today - do site exit routers need
        to signal hosts?

      - Lots of possible triggers - what triggers are valid?

      - Vertical signaling so you know when you can release state
        information?

      - Need to make decisions about dynamic locator sets - this would
        affect a lot.

      - Are there "distinguished locators" you always use to get a session
        up?

      - Is this purely IP datagrams?

      - Next steps - review SHIM6 contributions, solicit explicit answers
        from document editors, but this draft will be active for a while.




    Protocol
      document: draft-ietf-shim6-l3shim-00.txt
                draft-ietf-shim6-functional-dec-00.txt
      Erik Nordmark

      - We will not have a distinct namespace for identifiers.

      - We will not assume that a single FQDN is a single host (could be a
        multi-host service) - we'll try multiple initial locators until one
        works. Telnet does this today, so it's at least a plausible starting
        point.

      - Make sure we minimize failure impact during session initialization.

      - Don't force every connection to set up SHIM6 state.

      - Context establishment is a four-packet exchange - looks a lot like
        HIP exchange.

      - Include DOS protection on first packet received.

      - Since these were MULTI6 drafts, changes have been editorial.

      - Several open issues  - packet formats (including demultiplexing),
        state management, packet formats for control protocol, APIs for
        advice, path maintenance and exploration protocol), etc.

      - Pick one possible starting point and work out the details.
        Alternative would be using 8-byte extension header for data packets
        after failover.

          Pekka Savola - Do we need functional decomposition document? Seems
          redundant...

          Jim Bound - If we change the upper layer identifier, we break TCP.
          A lot of this stuff is already in SCTP now. Are we going to stay
          compatible with the old APIs? SCTP is in most of our stacks now.
          Are we going to dynamically change the ULID? Erik - no, locator
          changes won't be visible to TCP (for example). It is interesting
          to wonder about what SCTP over SHIM6 looks like... We're talking
          about adding a lot of code to production stacks.

          Pekka Nikander - If we are doing something at the IP layer, let
          the session-level state still be at the transport layer. We need
          to figure out SCTP over SHIM6. Why do we need anything in the IP
          header at all? After you have a failure, you want to be able to
          undo the address-swaps at the receiver correctly.

          Christian Huitema - there is a LOT of interaction with transport
          protocols. If we are assuming there's no impact, that's probably a
          mistake. Look at what should change in transport protocol if it's
          to take advantage of SHIM6. Need to interact with TSV working
          groups.

          Iljitsch van Beijnum - there are a handful of transports and
          millions of applications, and we are already concerned about
          changing transports...

          ??? If you're hiding multiple addresses, this may be sub-optimal.

          Pekka Nikander - as an implementation option, maybe you don't re-
          write the IP addresses, you pass them unchanged to SCTP? SCTP and
          TCP interfaces may look different in the future. May also need to
          think about path congestion versus session congestion - but this
          is research.

           Christian Huitema - there was running code several years ago for
           TCP address changing - the issue was making sure you weren't
           being spoofed when the addresses change.

    Crytpo Locators
       document: draft-ietf-shim6-hba-00.txt
                 refers to draft-ietf-send-cga-06.txt
       Marcelo Bagnulo, Jari Arkko

       - Concerns are preventing hijacking and flooding attacks in
         multihomed environments - generate a set of securely established
         prefixes

       - Idea is to contain information about the set in the identifiers
         themselves

       - Using the IID bits (like CGAs) for HBAs - HBA would be a CGA
         extension

       - Includes a mechanism to add prefixes dynamically using hashes and
         PK operations.

          Dave Thaler - How does this work with temporary addresses/private
          addresses?
          response: HVA set is fixed for a given communication, but you can
          have multiple HVAs.

          Francis Dupont - IPR status of HVA?
          response: No KNOWN IPR on this :-)

    Triggers
       document: draft-ietf-shim6-reach-detect-00.txt
       Iljitsch van Beijnum

       - goals - detect failures, and route around them ...

       - note that "address pair" is a unidirectional path.

       - Ping all source/dest pairs and pick best RTT or some other metric?
         Doesn't detect unidirectional paths, doesn't scale well (M x N).

       - Need better answer, so need more complexity - detect unidirectional
         paths, stop probing when you find a reasonable path.

       - Need heuristics (this is hard work), need a lightweight protocol.

       - "CUD", similar to Neighbor Unreachability Detection, or "FBD",
         requiring bidirectional communication (if you don't see
         bidirectional communication, do full reachability exploration).

       - CUD needs ULP feedback, FBD adds packets in an otherwise idle
         direction.

       - CUD detects failure in either direction, FBD in inbound direction.

       - Several choices on granularity (host to host, locator to locator,
         ULID to ULID, etc.).

       - NATs and Firewalls - protocol may be reused for IPv4, so ... would
         like IP options for fate-sharing, but this doesn't work with
         NATs/firewalls. How important is sneaking past firewalls?

       - Security - don't want too much reachability detection, but don't
         want too little :-) Must be lightweight!

       - Combine with draft on failure detection

          John Loughney - need to clarify (on the list) how to go forward
          based on architecture draft (transport layer? etc.) -
          response: this is in the absence of session information coming
          through transports, etc. - not either/or. Transports use ULIDs,
          not locators, so the point where mapping from ULID to locator is
          at the SHIM.

          Hesham - Can you assume that all the addresses on an interface are
          reachable?
          response: This is site multi-homing, not host multi-homing, so ...
          not in the SHIM6 context.

          Spencer Dawkins - can people send info on unidrectional
          applications to the list?

          Jason Shiller - is this just reachability, or degradation? Don't
          know the answer at this time.

          Tony Hain - assuming all links are equal? Path selection may
          depend on application (short T1 or long OC-48?) - use different
          ULIDs for different applications?


    Applicability
       documents: draft-ietf-shim6-applicability-00.txt
                  draft-ietf-shim6-app-refer-00.txt
       Joe Abley (reported by Geoff Huston)

       - very short draft, mostly placeholders at this time!


3. Discussion about approach

      - Geoff looking for co-author assistance with architecture draft

       - At IP level, all paths are the same - do we need a richer set of
         choices? Need to do design work here, especially for triggers.

       - Kurtis - Please put ideas into existing drafts, not into new
         drafts!

       - Christian Huitema - transport protocols determine whether a path is
         "good enough". Do we want to do this in IP, or expose information
         to transports that do it? What if we don't have a translation layer
         at all, and transports start doing this normally?

       - Iljitsch - need to do this at some point, but don't do it now -
         it's too early.

       - Hesham - what about applications?

       - Christian - two ways to solve this problem - API to push decision
         mechanisms, or keep IP the way it is. Not the same thing at all.

       - Hesham - in addition, there's also the factor of who makes the
         decision.

       - Pekka Nikander - yes, but most of this is implementation issue, not
         protocol issue. Simulation would be good!

       - Spencer - this is like the IAB Addressing workshop in Vienna -
         every layer does everything, this is not what we really want. Need
         to be really crisp here.

       - John Loughney - NS2 is good. We're talking about policy here - need
         to work through all of this from an application point of view.

4. Additional Items:

    Interactions between Shim6 and MIPv6
      document: draft-bagnulo-shim6-mip-00.txt
      Marcelo Bagnulo

      - This draft is informational for the working group at this point.

      - Need to understand interactions (SHIM6 over MIP6).

      - BT mode forces all traffic through home agent, if there is a
        failure, so SHIM6 detects failure and uses alternative home address.
        Or change care-of addresses?

      - RO mode give you two sets of paths (optimized and un optimized
        paths). One of the paths may fail, but not the other. SHIM6 uses
        alternative locator, same issue.

      - Should SHIM6 know about HoA/CoA?

          Spencer - OK, I was hoping that when I said each layer was in
          business for itself, I was hoping that was a bounded set of
          problems...

      - Charter says, "Don't break MIP6"...

          John Loughney - which one is on top? there is no assumption at
          this point. Mailing list to resolve this.

      - Do an API before November IETF?

    L3Shim state management using Vertical layered Communication
      document: draft-you-shim6-L3Shim-state-meagement-00.txt
      You Taewan


      - TCP Slow start is needed after path switch?

      - Will propose state management in more detail - if other protocol
        layer MAY be modified, will propose specific method.

          Spencer was going to say  - TRIGTRAN answer was that new path
          could be better or worse, simpler to let TCP figure it out rather
          than try to listen to hints. Mark Allman and Joe Touch were good
          sources on this. Answer may have changed, but that's what it was
          18 months ago.