SHIM6 - IETF63
Site Multi-Homing by IPv6 Intermediation WG (SHIM6)
Tuesday, August 2 at 0900-1000
Wednesday, August 3 at 0900-1000
Geoff Huston -- gih (a) apnic.net
Kurtis Lindqvist -- kurtis (a) kurtis.pp.se
Spencer Dawkins -- spencer (a) mcsr-labs.org
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.
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 signalling to include Loc Pair preferences to be expressed) in addition to sending the SHIM the trigger / heartbeat information associated with the current locator pair.
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
- 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.
documents: draft-ietf-shim6-l3shim-00.txt, draft-ietf-shim6-functional-dec-00.txt
- 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
- 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
- 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.
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:
- CGAs - public key crypto base
- CGA & HBA - hash contains public key and prefix sets and the ability to add new prefixes
- 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.
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: