-Minutes :


Multi6 working group
====================


Wednesday 3 March


Agenda:


    1. Agenda bashing and Administrativia, chair


    2. Charter review, chair


    3. Short intros to NEW drafts
       draft-ohta-multi6-threats-00.txt, Masataka Ohta
       draft-ohta-multi6-8plus8-00.txt , Masataka Ohta
       
draft-ohira-multi6-multilink-auto-prefix-assign-00.txt, Kenji Ohira
       draft-arifumi-multi6-tlc-fm-00.txt, Arifumi Matsumoto
       draft-ylitalo-multi6-wimp-00.txt, Vessa Torvinen
       draft-nikander-multi6-hip-00.txt, Pekka Nikander
       draft-coene-multi6-sctp-00.txt, Lode Coene
       draft-crocker-celp-00.txt, Avri Doria
       
draft-toyama-multi6-operational-site-multihoming-00, K. Toyama


    4. 
draft-lear-multi6-things-to-think-about-00.txt, Eliot Lear


    5. Architectural analysis, Geoff Huston


    6. Other issues



1. Agenda bashing and Administrativia
=====================================


    Brian Carpenter is not here today, so only Kurt Erik Lindqvist will 
chair the session.


    Session is broadcasted.


    Comments on the updated charter by Kurt Erik Lindqvist.
    Some modifications have been proposed to the charter. The updated 
charter has been sent to the IESG. The IESG then made some comments and 
those are being solved.
    There are new milestones, including:
    - Architectural evaluation for Feb. 04, which is expected to be based in 
the work done by Geoff Huston. April timeframe was considered. This draft 
will be used then to classify and evaluate proposals.
    - Informational draft about current multihoming practices in IPv4, as 
confirmed in the Vienna meeting. A draft exist covering this issue, but is to 
be updated. No much feedback about the draft yet. The chairs may need to 
find an editor for this.
    - Operational draft containing practical questions. The proposal is to 
base it on 
draft-lear-multi6-things-to-think-about-00.txt by Elliot Lear. The 
proposal is to obtain more discussion on this and then send it to last 
call.
    - Threats draft. The proposal is to base it on 
draft-nordmark-multi6-threats-00.txt.


    Questions:


    Pekka Savola: I am concerned about ID about current IPv4 
multihoming today, there are still big issues with it. Is it already 
submitted?


    Kurt Erik Lindqvist: It has not been submitted yet, the chairs need to 
decide how to move forward with this.



Decisions/Outcomes
==================


1. Adopted 
draft-lear-multi6-things-to-think-about-00.txt as a working group item.


2. Geoff Huston will produce a draft containing the architectural
   analysis.


3. Erik Nordmark will update the security threats draft


4. Possible interim meeting to be defined.


00 Draft Presentations
======================


Threats Relating to Transport Layer Protocols Handling Multiple 
Addresses

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


    Masataka Ohta
    Multiple addresses assigned to homes in multihomed sites are needed in 
order to preserve global BGP routing table small.
    A session is something that needs state, so it is not at the IP 
layer, since no per connection state exists in IP.
    The connection state resides at the transport layer.
    So, this draft analyses the threats in transport layers managing 
multiple addresses.
    Threats:
    - Connection hijacking: it is not a new threat, since MITM in DNS 
queries/replies or rewriting an URL in HTTP can cause similar effects. The 
solution for this is to protect with cookies and this solution is 
already considered.
    - DDOS: The problem is amplification, This is not new threat, since it is 
similar to, for instance, what happens in the DNS, where the reply is 
longer than query. A multihoming solution should not generate answers that 
are longer than requests. However, new DOS opportunity can be caused by the 
usage of public key crypto in multihoming solutions, because public key 
crypto is costly. Cookie based solutions are not so expensive.
    - Privacy in the identification: A multihoming solution should allow to 
hide the identity information, so it should be allowed identifiers to be 
temporal.



8+8 Addressing for IPv6 End to End Multihoming

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


    Masataka Ohta
    8+8 addresses is an old concept, and it is based are composed by 8 
bytes locators (used for routing) and 8 bytes identifiers (used for 
identification). For multihoming support with multiple addresses, the 
support cannot be provided by the IP layer, because IP is stateless.
    This proposal does not change IP.
    8+8 addresses the issue of interoperability with legacy hosts. For this 
it is necessary to discover when to use 8+8 capabilities i.e. whether the 
other end of the communication supports 8+8.
    The proposed solution is to use the group bit in the identifier to 
signal if the the node supports 8+8 mode.


    Question:
    ??: Are you proposing to use the group bit for this?
    Masataka Ohta: this bit it is not used today.


    Continue with presentation:
    A problem is how to distribute identifiers, in this case 
identifiers can be assigned like DNS names, since you can base the 
identifiers in the locators.
    Locator selection is not a problem because the global routing table is 
used for that.
    Source locator is not an issue, since source address is ignored.
    In the case that some issues related with ingress filtering 
compatibility appear, they can be solved through a modification in the IGP 
(such as OSPF modification).
    There are no problems with Mobility.
    The solutions proposes to modify TCP, but in a fashion that it is 
compatible with old TCP.
    The solutions presents all the desirable properties presented in RFC 
3582.



Hierarchical IPv6 Subnet ID Autoconfiguration for Multi-Address 
Model...

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


    K. Ohira
    Multiaddresses is proposed in several solutions
    This solution proposes an address assignment protocol to assign 
multiple addresses to host in multi-link multihomed sites.
    It is assumed that source address based routing will be used to 
select the exit.
    Transport survival is out of scope.
    The protocol proposed to assign addresses is the following:
     - Assign subnet identities to each link, by dividing the subnet field  
in the IP address
     - The top level router i.e. the one connection to the ISP, obtains a 
/48, and splits it downwards.  RFC 3582 assessment slide



TLC-FM : Transport Layer Common Framework for Multihoming

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


    Arifumi Matsumoto
    Fate sharing based classification of different type of solution:
    - SCTP, TCP-MH and DCCP: each layer has its own multihoming 
information which is not shared with other transport layers.
    - Wedge solutions: the multihoming information affects all the 
sessions in the host. The problem with this approach is that each 
application cannot choose its own paths
    TLC-FM proposes to use an intermediate level of fate sharing 
(information shared). Each transport shares the information with other 
transport layers.
    However, each transport chooses the path for its packets, and it also is 
responsible to detect outages in the currently used path.
    The information that is shared is the path information, where a path is 
defined as a destination address, a source address and a next hop.
    Next hop information is especially relevant for multilink hosts. The 
information about the quality of the path should also be shared because it is 
useful when selecting a path to avoid network failures.
    Failure detection is performed by each transport using different 
mechanisms:
    - TCP: data retransmission
    - UDP: received ICMP messages (Destination unreachable, Time 
exceeded) and it can also use some help from applications (requiring a new 
API to notify outages)
    TLC-FM needs a control channel to inform about the addresses 
available.


    Questions:
    Pekka Nikander: It is an interesting proposal. Isn't similar to CELP?  
Perhaps it should be joined with CELP?
    Arifumi Matsumoto: It is similar to CELP. The difference is the 
policy since each transport can have a different path.


    Erik Nordmark: How do you apply this to SCTP considering that SCTP test 
its own path? You probably want to share the path test information too for 
performance benefits.
    Arifumi Matsumoto: The problem is that such feature is not 
available in other protocols.



Weak Identifier Multihoming Protocol (WIMP)

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


    V. Torvinen
    The basic assumption is that there are lighter operations than public 
key crypto.
    The basic operations are much faster.
    WIMP has two main components: a context establishment phase and a 
readdressing protocol.
    WIMP uses non routable endpoint identifiers. Identifiers are hashes of 
strings (fqdn,and ephemeral identifiers). The reason for that is not to 
allow the attacker to steal the identifier.
    Basic cryptographic concepts used:
    - Hash chains: recursive calculation of hash starting from a random 
number and then feeding the next hash with the output of the previous 
hash. The main characteristic of this chain of values is that it is 
impossible to know the next value from the previous one, but you can 
verify the previous value.
    - Secret splitting: it is used to send parts of the spit secret 
through multiple paths, assuming that no one attacker can intercept all the 
paths during a readdressing operation.
    Basic operation: 4 way handshake is used to establish context. The 
anchor values of the initiator and responder hash chains are exchanged 
during this handshake. It is vulnerable to MITM attacks at the initial 
exchange.
    Major comments received are about endpoint identifiers and flow 
identifiers.


    Questions:
    Elliot Lear: This looks similar to Purpose Build Keys? Is it 
similar?
    Pekka Nikander: The goal is the same, but WIMP uses hash 
operations instead of public key crypto, which provides same 
functionality with better performance
    Masataka Ohta: Sequence numbers can also be hashed with a key and it is 
just as good, and why do you split keys?
    V. Torvinen: We split the secret to make return routability to the new 
addresses.
    Masataka Ohta: This can be easily snooped.
    Erik Nordmark: Return Routability test is used to verify that the end is 
at the address that it is claiming.
    Margaret Wasserman: Good draft, but about secret splitting usage, it 
seems that you have to reach the host at the previous address, what 
happens when the host is no longer available at the previous address?
    V. Torvinen: We haven't considered mobility. In the considered case, the 
initiator informs about the locators he wants to use.
    Pekka Nikander: Just to clarify about this, there are two options 
here. One is to run the address exchange protocol before loosing the path, so 
when the path is gone there are no problems. The other option is to split 
the secret in such a way that it is good enough to obtain only some of the 
parts of the secret.
    Margaret Wasserman: How fragmentation and PMTU discovery are 
handled?
    More comments on the list.



Lightweight hip with delayed setup
----------------------------------


    Pekka Nikander
    The biggest criticism received when trying to apply HIP to 
multihoming is that hip is too heavy.
    HIP in opportunistic mode provides protection against everything but 
initial MITM attack.
    The proposal is to preserve current level of security with less cost, by 
combining WIMP and HIP.
    The idea is to combine initial 4-way exchange of HIP and WIMP, so that 
initial messages carry both HITs and MAC of the anchors.
    The receiver then can choose to use HIP or WIMP. So the 
communicating nodes can continue to use WIMP as long as they want, but they 
feel that they are facing an attack you, then they can run full HIP to 
protect themselves.
    Still more in depth analysis of the potential introduced 
vulnerabilities is required.


    Questions:
    Richard Graveman: IKEv2 provides same features and also protects from 
initial MITM
    Pekka Nikander: You need PKI to protect initial MITM, since in 
opportunistic mode you can't protect initial MITM attack.
    ??: do you use IPSec in light mode?
    Pekka Nikander: no.



Multihoming: the SCTP solution
------------------------------


     L. Coene
     This draft essentially asses the SCTP multihoming solution with
     
draft-lear-multi6-things-to-think-about-00.txt
     - No rendez vous for mobility are considered, since SCTP only 
performs the handover.
     - No additional latency, because data and control traffic are 
transmitted together.
     - No problems with DNS since it is only used to get an initial 
address.
     - For authentication: the proposal is to use PBK, and it seems that it 
will work.
     - How does the host knows its own ids? SCTP tries a subset of the IP 
addresses assigned to the host.
     - No extra load for DNS.
     - No extra upstream ISP support required.
     - The solution impact on the different sizes of sites from SCTP 
perspective is none since, SCTP doesn't care about the amount of 
addresses being handled.
     - About referrals:


     Question:
     Elliot Lear: the referral point is related to applications like FTP.
     Margaret Wasserman: Referral is not only about A telling B how to 
contact C, but also about A telling B how to contact A two hours later.
     L. Coene: I will review the referral aspects.


     Continue with the presentation:
     - No application changes are required
     - IP issues are solved in Christian's draft


     Questions:
     Margaret Wasserman: how does the draft addresses the point 
included in the goals draft?
     L. Coene: I forgot to include these points.
     MW: the goals draft require TCP and UDP support, how do you deal with 
that?
     LC: It is not supported
     Kurt Erik Lindqvist: RFC 3582 is a goals document, not a 
requirement document.


     Continue with presentation:
     Conclusions:
     - Some applications may be migrated to SCTP.
     - Reports about ADDIP messages in next meetings.
     - Deploy SCTP in carrier networks with multihoming support.
     - There is some work going on about multipath.


     Questions:
     Erik Nordmark: Is there some experience about selecting locator and 
paths available?
     LC: We are trying to collect the information. If IP is not working 
properly, there are problems. We are trying to collect more 
information about this.



Framework for Common Endpoint Locator Pools

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


    Avri Doria
    There are multiple multiaddressing schemes, so we are looking for 
commonalities between them, so that they can share the work done by the 
other mechanisms available in a host, sort of an opportunistic use of 
other's information. The goal is to reduce transaction cost.
    There are two types of schemes identified : transport approaches and 
wedge approaches. Each approach has its benefits, but not all them solve all 
the problems.
    The proposed approach is to create common locator pools, so that both 
transport and wedge solutions can contribute to it.
    Different granularities are proposed for the stored 
information: host, flows, protocols, ToS
    The next step is to look at each multiaddress solution to see what they 
can provide.
    Each solution can insert information into the pool, and also benefit 
from the information available in it.
    There are several issues but the idea is to start with a 
simplified mechanisms and then go to more complex solutions.
    There are also some security issue related with how do manage when 
multiple solutions with different levels of security insert 
information into the pool.
    Other issues related to names used to identify locators pools.
    The next steps are: resolve the security and naming issues above.
    Go through other proposals, as stated earlier. Identify near term 
issues and longer term issues.
    All proposals have value and probably many of them will de 
accepted.


    Questions:
    M. Ohta: Different protocols have different ideas about the 
availability of paths, retransmission times and so on. Since this 
information is protocol independent, so you cannot share the 
information.


    AD: Different attributes for different pools can characterize that, and 
the administration of the pool is complex, so that for each protocol you 
need specific information.


    M.O.: But if you make it protocol wise, you don't have shared 
information then.


    Kurt Erik Lindqvist: Take it to the list.



Operational Approach to achieve IPv6 multihomed network

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


    K. Toyama
    In IPv6, it is assumed that only aggregated routes will be 
advertised globally.
    This is a routing based solution, wihtout affecting the global 
routing table.
    It is proposed that a /32 and an AS number is assigned to the 
multihomed costumers of a group of ISPs, and that a /48 of this /32 
assigned to each multihomed site.
    Peering relationships are established between the involved ISPs that 
serve the multihomed clients, so that each ISP injects the complete 
aggregate to the Internet.
    So the ISPs cooperate.
    The request is to allow the allocation of the resources required by the 
solution.


    Questions:
    Erik Nordmark: what happens if one of the ISPs goes down 
completely?
    K.T.: The other one provides backup.
    Elliot Lear: this solution can be implemented wihtout changes, but have 
you talked to ISPs about how do they feel about implementing this?
    K.T.: Not all pair of ISPs will want to cooperate.
    Francis Dupont: I have published something similar a long time ago.
    Peter Lothberg: There is not a single cloud which is the global 
Internet.


End of 00 presentations
-----------------------



Presentations about specific charter items

==========================================



Things MULTI6 Developers should think about

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


    Elliot Lear
    This is not a requirements document.
    It contains things beyond multi6 scope.
    It is not an architectural draft, it is about operational issues.
    It is not a position paper.
    It is a collection of operational questions, several of them are 
interrelated.
    For instance performance and security issues are considered in all the 
document.
    Key issues considered in the document:
    - Protocol on the wire: packet format changes introduced? and in which 
layer? Why that layer was selected? Impact on transport layer (pseudo 
header)?. Required changes on fragmentation? Additional latency? Are the 
changes required by all hosts or only multihomed hosts?
    - Security: How do you secure the binding between different names 
involved? Are there any new DOS opportunities created? Do you rely on 
other security infrastructure?
    - name/binding issues: Which is the lifetime of the binding? How is the 
binding updated? Do you introduce a new namespace? if yes, then, how does it 
looks like and how is it managed? Which is the relation with DNS?Is there 
any upstream ISP support required? Are there any dependencies on middle 
boxes? if yes, then what if they fail?
    - If the DNS is used: are there any circular dependencies between DNS 
and the routing system. Are there any new RRs? Is the FQDN goes in every 
packet? How is two faced DNS supported?


    Question:
    Pekka Savola: circular dependencies are more general than only to the 
DNS.
    E.L.: Yes.


    Continue with presentation:
      How does a host knows its own identifiers? Does the solution place an 
additional load in the DNS? Is DNSSec performance an issue?
    - Application implications: is it a new interface required? How do you 
support referrals like ftp, sip?
    - Backward compatibility: How the solution works with old IPv6? Can old 
IPv6 devices benefit from the solution? Do non-multihomed sites have to 
make changes? Changes are required on hosts, routers, both?
      Are there any changes in the management model?
      Two tests are suggested: how do you implement your solution in an 
IETF conference network? Have you tried in a lab?
    - Legal stuff: Do you create a new mnemonic namespace? How do you 
manage it?
    The goal of the draft is to compare results between proposals, 
creating a matrix to compare results. Perhaps even to merge similar 
solutions.


    Question to the Working Group:
    How many people have read the draft? Many hands. Do you think it needs 
more detail?
    M. Wasserman: It should be a living document, since changes will be 
introduced in the future. One thing I like to see added, about have 
delayed setup. When I start talking, do I need to know if the other end 
supports the multihoming solution? Another issue is, do we know which are 
the right answers?
    E. Lear: We should determine the set of important questions.
    Kurt Erik Lindqvist: Application people input is required. Security 
issues are listed, so the idea is to list the goals for security in each 
proposal. We don't want the document to contain the answers of the 
questions, we leave this for later.
    Pekka Savola: Some issues should be expanded, like what are the  
critical things. Some of the answers for this questions provided by the 
solutions are missing the point, so perhaps we should clarify.
    M. Ohta: The draft is very good, the checksumming issue should be 
included.
    K. Lindqvist: This is one of the new charter items, so


    Question to the Working Group: Who wants this as a working group item?
    Many hand for yes and no hand for no.



An Architectural View of Multi6 proposals

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


    Geoff Huston
    Clarification: specific proposals are used just as examples.
    There is a very large amount of proposals and some look similar.
    The goal is to try to make a taxonomy based on the 
architectural goals of the proposals.
    Problem space is a multihomed site. Note that there may be more that two 
ISPs, and that communications don't only involve 2 parties always.
    Exit routers and hosts appear because they are included in several 
proposals.
    Presentations of the goals presented in RFC 3582 and some of the 
questions of Elliot's draft.
    There are three mayor approaches:
    - Wedge a new layer in the stack: Based on Soch's work (who, where and 
how) while in IP only the IP address is used for all of them. These 
proposals are trying to disambiguate the who from where and how.
    - Modify the stack, whether transport or IP
    - Modify the local interaction: Destination based forwarding 
algorithm is modified to select the right exit.
    Wedge solutions.
      Can be placed above IP or above the transport layers. Most 
proposal are below transport. ULP deal with an identity token and IP deals 
with locators. The hosts control the locators set but the ULP are not 
aware of the changes. There is an identity peering between the 
communicating hosts.
      There are many ways to do this:
        - Conventional: add a new OSI layer -> new header trailer, 
communication in band.
        - New control channel (out of band): can communicate even 
without data. It has its own triggers.
        - Refer to a third party, like the DNS.
      While architecturally all are the same, there are changes in the 
implementation.
    Modification to existent layers.
      - Fatter transport: SCTP example where pools of locators managed by 
transport. A new transport is needed.
      - Modified IP: One IP address is an alias for identity and the other IP 
address is an alias for location.
    Modified host/router interaction
      - Doesn't fit the layer model nicely.
      - The problem solved is that when a source address is selected and
        the wrong ISP is used, the packet is discarded
      - This means that when selection the source address implies a 
topological decision.
    IPv4 multihoming style: not an option?
    Common issues identified:
      - Required locator selection mechanisms by the host.
          - One's source locator is the other's destination, so this 
selection imposes the reverse path.
          - How is the selection among different destination locators?
          - How do you change locators once that the selection is made? 
when a change is needed? how are network failure detected?
    Some examples of analysis for proposals:
      - HIP: Shim layer between transport and IP. A stable identifier is 
presented to transport layer. Multiple locators are bound to a fixed 
identifier. So, locators can change in a session.
      - SIM, NOID and CB64: Shim layer approaches. NOID is 
referential, SIM uses protocol exchanges and CB64 is hybrid. 
Additional elements since exit router rewrite packets
    About namespace structure:
      - Hierarchical
         -Identifiers are part of the IP address space.
         - FQDN are used. Problems with the interaction between DNS and 
routing. The DNS may not be good enough for this mapping
         - New token: why is it needed? what feature is not available in 
existent namespaces?
      - Opportunistic: no need to manage the name space. How referrals are 
handled?, How searches are performed?
    SCTP: Heartbeat required to trigger locator change
    MIPv6: Only one locator valid in a give moment, encapsulation 
carrying the locator in the outer header and identifier in the inner 
header
    Modified host/site-exit interaction: Site forwarding paradigm is 
changed. Multiple options, like anycast address, source address based 
forwarding, source address rewriting.
    Other option is to provide a solution for the initial problem which is 
ingress filtering, so just release ingress filtering.
    Common issues:
    - How do you select best source locator?
    - How do you select the best destination locator?
    Detecting network failure
      - Heartbeats
      - Transport
      - ICMP from router
      - Note that failure between startup and once the session is 
established
    Security is not in the scope of this work, worthy of a separate 
analysis


    Questions:
    Erik Nordmark: The approaches that change the host/router 
relation, make the edge more explicit?
    G.H.: Yes, perhaps reality is not like this.
    E.N.: Are there any other architectural implications with making this 
border explicit?
    G.H.: If this model is mapped to reality, do you have a clean idea of 
what the exit is?
    M. Wasserman: what is the process in order to move more into details 
from here?
    Kurt Erik Lindqvist: Doing a document about proposals doing an 
evaluation referred to this taxonomy, and classify the proposals 
according to this. Besides with Elliot's draft we could have a 
benchmarking of the proposals.
    M.W.: I am worried that the architectural analysis is based on 
proposals, and that what is not covered by proposals is not included in the 
analysis.
    K.E.L.: Many proposals overlap, so we need to group them together
    Dave Crocker: Multihoming and mobility can be covered with similar 
mechanisms
    G.H.: I think the assumptions made by the solutions in both cases is 
that the identifier can be used as a glue between locators.
    D.C.: It may be complex if we try to solve all the problems in one and it 
may take forever. OTOH, separate solution may make things even more 
complex.
    Pekka Savola: A general comment: To progress we have to figure out 
deployment scenarios, and not only one solution will fit all the 
scenarios.
    K.E.L: Yes, that is why the document describing current IPv4 
multihoming solutions is needed.
    James Kempf: Define deployment scenarios and simulations to see how 
this work
    K.E.L.: last comments on how do we proceed. The assumption was that 
Geoff would write a document with the architectural analysis.  
Additionally, we have to move forward the threats draft. Perhaps an 
interim meeting is needed.