[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Minutes from the multi6 WG at IETF59
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thanks to Marcelo for taking the minutes!!!
- - kurtis -
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 solutions:
- 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.
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3
iQA/AwUBQEa0JqarNKXTPFCVEQL6JwCdGV51R7jtPApBoh9mdqnGRjGd/g0An3P4
F/cjTh0tiPEuSt/uk/Q7mHcF
=vh7l
-----END PGP SIGNATURE-----