Site Multi-Homing by IPv6 Intermediation WG (SHIM6)

1. Agenda Bashing

• A very tight agenda.
• No agenda 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 in terms of deadlines for activity.
• 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

documents: 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. We will then use explicit locator set establishment to ensure that we are collecting the locator set for the host.
• Make sure we minimize failure impact during session initialization.
• Don't force every connection to set up SHIM6 state. Attempt to share state across multiple sessions in order to minimize overheads. Use heuristics to determine when to commence with a SHIM6 capability query.
• Context establishment is a four-packet exchange - looks a lot like HIP exchange. Include DOS protection on first packet received, and delayed state establishment, where initial response is conformation of capability without state creation. Second packet pair establishes state.
• Since these were MULTI6 drafts, changes have been editorial.
• Several open issues:
  • packet formats including receive-side demultiplexing considerations,
  • state management,
  • state removal,
  • packet formats for control protocol,
  • APIs for ULP signaling,
  • path maintenance and viable locator exploration protocol), etc.
• Next Steps: Pick one possible starting point and work out the details. e.g. Could use the flow label for receiver demux signaling, or an alternative would be using 8-byte extension header for data packets after failover. Make some specific choices and develop the approach.

  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 rewrite 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, also refers to draft-ietf-send-cga-06.txt
Marcelo Bagnulo, Jari Arkko

• Concerns are preventing hijacking and flooding attacks in multihomed environments. Need to generate and exchange a set of securely established prefixes.
• Idea is to contain information about the set in the identifiers themselves, taking a hash function of the locator prefix set in a particular order and a random number field.
• Using the IID bits (like CGAs) for HBAs - HBA would be a CGA extension. Need to know the locator set in advance as this is not a construct that allows dynamic change while keeping the HBA constant.
• Includes a mechanism to add prefixes dynamically using hashes and PK operations and generating a new HBA.
• Issue of CGA / HBA compatibility. e.g. SEND uses CGAs, and HBA and SEND could collide. CGAs provide support for dynamic sets. The option is to define HBAs as a CGA extension. This results in 3 address types:
  1. CGAs - public key crypto base
  2. CGA & HBA - hash contains public key and prefix sets and the ability to add new prefixes
  3. HBA only - fixed prefix set
• Security considerations: basic attack - attempt to produce an HBA with a different set. The difficulty is to find an interface identifier that fits the target hash. Since the order of the prefixes can be changed the IID's will be different for each prefix.

  Dave Thaler - How does this work with temporary addresses/private addresses?

  response: HBA set is fixed for a given communication, but you can have multiple HBAs.

  Francis Dupont - IPR status of HBA?

  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.
• First order approach would be to ping all source/dest pairs and pick best RTT, or some other metric. This approach doesn't detect unidirectional paths, doesn't scale well (M x N).
• We need better answer, so likely need higher complexity in order to detect unidirectional paths, and to determine when to stop probing when you find a "reasonable" path.
• Need heuristics (this is hard work), need a lightweight protocol.
• Correspondent Unreachability Detection - CUD, similar to Neighbor Detection, but at a multi-hop distance. Requires bidirectional communication (if you don't see bidirectional communication, then there is a need to do full reachability exploration). Need to signal "progress" from the upper level in the result of upper layer trouble then do correspondent testing CUD needs ULP feedback.
• Forced Bi-directional Communication - FBD adds packets in an otherwise idle direction (keepalive approach).
• CUD detects failure in either direction, FBD in inbound direction.
• The full detections is preferably avoided as this is a high overhead. Then if we still have connectivity then the retest of this path is simple - only get into the full procedure when there is a problem with timeout of response.
• The session transport protocols need to cooperate - in the absence of upper layer signaling then the shim turns to pseudo-transport to maintain state.
• 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 unidirectional applications to the list?

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

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

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