[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ascii-formatted version of the multi6 minutes from IETF58 - please send me corrections
Multi6 Working Group
--------------------
Session 1
Tuesday 11 November
Agenda:
* Agenda Bashing and Administrivia
* Design Team 2 Update
- Marcelo Bagnulo / David Kessens
* Dave Crocker
- draft-crocker-mast-analysis-01.txt
- draft-crocker-mast-proposal-01.txt
* Arifumi Matsumoto
* Masataka Ohta
- draft-ohta-multihomed-isps-00.txt
* Kenji Ohira
- draft-ohira-assign-select-e2e-multihome-02.txt
- some research results about implementation of SABR
Session 2
Wednesday 12 November
Agenda:
* Erik Nordmark
- draft-nordmark-multi6-noid-01.txt
- draft-nordmark-multi6-sim-01.txt
- draft-nordmark-multi6-threats-00.txt
Agenda Bashing and Administrivia
================================
Scribe: Geoff Huston
WG Chair announcement: Sean Doran has stepped down as co-chair of the
Working Group. Brian Carpenter is co-chair for the working group for
this week.
Shortened agenda for Tuesday to allow a break to attend the IPv6 WG
meeting
RFC3582 (Goals for IPv6 Site-Multihoming Architectures) to measure
proposals has been published. Each presenter has been asked to
measure their proposal against the parameters described in this
document
Decisions / Outcomes
====================
1. The WG should evolve the threat work (as documented in
nordmark-multi6-threats) with solution development.
2. Chairs to set a date for the submission of ideas regarding
approaches to multi-homing - mid-January appears to be the
preferred deadline.
3. Take the topic of evaluation criteria for WG to use to the
mailing list.
4. Eliot Lear to prepare a draft on criteria for analysis of MH
proposals.
5. Jim Bound to draft a proposal using SCTP + NOID with TCP emulation
layered above SCTP.
6. Pekka Nikkander to prepare a HIP based MH draft
7. WG to consider how to converge ('marry') these proposals into a WG
proposal from this set of individual proposals using an approach of
functionality analysis of the proposals.
Presentations
=============
Design Team 2 Update
--------------------
Presentation
- Design Goals outlined, with a reduced set of requirements as
described in draft-huitema-multi6-experiment-00. The approach
described as incremental with minimal changes to external hosts.
- testbed described
- Normal Operation - source address based routing, load sharing and
policing
- fault Tolerance - 2 cases: outage in link between mh sites and
direct ISP - RFC3178. Outage in other elements is reference to
RFC3484 from externally-initiated comms. Internal initiated
communications retry with a difference source address
- summary - a lot of features that only require some additional
configurations. Internal hosts require modifications for
internally- initiated communications. External hosts require
changes to preserve comms in external-initiated communications
- The capability against RFC3582 presented
Clarification questions:
How is the ingress filtering from the ISPs circumvented?
Source address-based routing in the site's boundary routers -
packets will be forwarded from one exit router to another based
on source address.
How would this work if the routers were not on the same subnet?
The model assumes a subnet in this presentation, and the remote
case may require additional internal routing capabilities
Design Team 1 Update
--------------------
Presentation
- extensive update provided in Vienna - this one is more succinct.
Erik Nordmark will cover the substantive issues in the subsequent
WG sessions
- the essential element is the use of explicit identifier / location
identifier split using a shim layer to map between the two identity
spaces.
- the design team is considering a number of aspects: threats,
- threats to be addressed in next session
- issues similar to mobility in v6, but mobility approaches can't be
directly mapped due to multi-homing differences
- NOID
- no identifier beyond FQDN. FQDN is not to be loaded into packets,
and upper layer protocols chose a locator and the shim layer
allows the upper layer to continue to use this locator even in
the event of home changes.
- CB128
- the shim layer performs a reverse -> forward -> reverse DNS
lookup
- another approach uses a 128 bit crypto-id, similar in some form
to the HIP approach, but with different mechanisms.
- locators can't be found from IDs in this case
- CB64
- alternate approach with 64 bit hashes
- cryptoid
- similar to cb64 with internal structure within the identity
space. Locator and ID bits can appear on the wire.
Analysis
--------
Dave Crocker
- framework for the approach is a similarity in multi-homing and
mobility. The stated difference is one of the time base for the
multiple addresses in play.
- lengthy considerations sections
- infrastructure approach uses an agent that works on behalf of one
end of the communications
- shim or wedge is a full function layer that sites only in the end-
points, not in the transit operation. Mast is one of these. HIP is
another, and there are some other 4 or 5 noted. The end-to-end
communications is without intermediaries. The shim layer is a
rendezvous-styled operation
- transport layer approaches
- comparisons of these approaches include the match against the goals
document, and it is claimed that there are more considerations
here.
MAST
----
Dave Crocker
- goal of maintaining locator pools. The application's awareness of
the locator pool is mute. Claimed to make renumbering easier
- terminology listed. multi-addressing is claimed to be relationship
across multiple packets that pass across the infrastructure.
- identifier to locator mapping is one aspect. locator selection is an
open research topic, if there is more that one locator.
- architecture knowledge of multiple locators goes to endpoint modules
within the host, but no further. The endpoint module will map from
an eid string to a locator. Each host loads its locator as an 'open
question'. NAT traversal is described by a mirror query to the
remote end to locate the own external locator. DNS and presence is
included as a means of getting a current locator using a presence-
style service.
- operator - locator discovery and locator selection. The discovery
operation is 'normal' DNS for fixed. DNS + dynamic mechanism to
retrieve current locator. Locator interruption can be undertaken by
MAST peer-to-peer
- locator pool maintained through MAST mechanism
- security only equal to IP. The recognition of 2 packets belonging to
the same sequence have a number of choices. For global persistency
global DNS is proposed. A NONE is proposed to be sufficient for
mobility
- table of comparison presented.
TCP Multi-Home Option
---------------------
Arifumi Matsumoto
- DT2 - host-centric model, source-address based routing within mh
site. Improved TCP is necessary and claimed to be simple. SCTP is
not TCP as there is no interoperability between SCTP and TCP
endpoints in a single session. This approach is TCP MH Options
- TCP - add MH option only. claimed to allow rapid recovery from
transmission failure. after RTO timeouts the pool of source
addresses is used to use a new path
- protocol exchange illustrated. SYN packet contains MH option that
includes the intention to use different source addresses.
- bit format for MH options presented.
- path switch triggered on TCP timeout or ICMP error
- path discarded under certain conditions
- security considerations: redirection attack - claimed to be easily
prevented in this approach. Session hijack protected by strict MH-
Serial number management, backing out when incorrect serial
received.
- not the consensus of the DT2 team.
- table of comparison presented
Clarification questions:
* What to do with UDP?
UDP need not be considered within this context.
* Why are TCP enhancements is showing up here first? This should be
targeted
at transport area!
(Chair) This would be referred over if we proceed in this way
* Redirection attack is possible on guessing the 16 bit number.
Protection is based on not being able to guess this 16 bit number,
correct?
yes, although there are other protections here to reset the TCP
session
Global Routing Table Size
-------------------------
Masataka Ohta
- the goal in multi6 is to make the global routing table small
- how small at the lower limit?
- small routing table is claimed to be a desirable goal
- mh is multiple links with separated sites for boundary routers
- full route sets are necessary on the 'site backbone'
- a full routing table on hosts allow a host to carry unreachable
locators and metrics for each locator
- source locators must be 'proper'
- let hosts select the source locator, routing protocol to carry
source locator to be used for each destination
- policy control is 'not so global'
- the global routing table size should be larger than the number of
Tier 1 ISPS. An upper limit should be imposed by memory and
bandwidth of a host. Presentation makes some assumptions to
calculate this figure, and postulates that the global routing table
should be upper limit bounded at 8,000 entries in the global routing
table.
- table of comparisons
Source-Based Routing
--------------------
Kenji Ohira
- characterizes some solutions as above IP and below TCP, others are
TCP augmentation /alteration
- target is small stub networks, not ISP multi-homing
- method proposed of hierarchical addressing and source-based routing
- updates from original draft listed
- table of comparison provided
Lin6
----
Masahiro Ishiyama
- location in dependant networking
- implementations
- uses globally unique id in low 64 bits and network prefix in upper 64
bits
- locator resolution uses a new agent - a mapping agent - to perform
this resolution
- assume that the ID is statically assigned - now working on a dynamic
assignment mechanism with a crypto base with the mapping agent
Multi6 Threats
--------------
Erik Nordmark
Why?
- adding this additional level of indirection to the architecture
opens up security vulnerabilities
- can be used to divert traffic and potential denial of service to a
3rd party
- similar to mobile ipv6, but not identical
Today's assumptions
- how good security - no better, but not making it any worse
- option to use the DNS and trust what comes back
- applications that trust the source IP addr of received packets
without any verification of information - these are vulnerable to
various forms of attack
- the existence of reverse+forward DNS resolutions was noted
- using security mechanisms and their notions of identity
- opportunistic security without access control
Redirection threats today
- compromise the routing protocol
- compromise the DNS
- ND/ARP spoofing
- attack a node on the path
- mh solution should not make things any worse
Flooding attacks today
- send packets to target
- self-flood or flood path to self (e.g. ACK spoofing)
- reflection attack where A can direct B to send to C, with out
without amplification
- we don't need to fix these problems, but should avoid making them
worse
New attack vectors
- redirect existing flow to a new locator
- predictive attack (if A will talk to B, C claims to be A before A
communicates with B)
- replay attack
- black hole by broadcasting a broken id/locator binding
3rd party DOS attacks
- redirection to flood a 3rd party
- possibly a check that the endpoint is reachable at the location
prior to data flow as a mitigation
Accepting Packets
- With ingress filtering at all locations its hard to inject a
spoofing packets
- mh potentially allows any source, compromising ingress filtering
Multiple Multi6 Approaches
--------------------------
Erik Nordmark
- A number of solution proposals with inherent trade-offs
- NOID, SIM and CB64 as a shim between ULP and IP, below
fragmentation, AH, ESP and destination options, and above IP
'routing'
- Application / ULP uses an ID that is stable for a session or
longer. This IS is termed the 'AID'
- mh uses different locators over time
- rewriting of source locators to detect changes
- Uses DNS without changes
NOID
- no identifier in any packets. The FQDN is the node identifier, and
a set of locators are used on the wire.
- The ULP uses a single locator during a communications
- different connections use different locators to allow load-sharing
- shim layer can use different locators on the wire
- receiver needs to rewrite locator according to current context
NOID - DNS
- uses reverse + forward to prevent redirection attacks
- this provides the FQDN and a working reversed
- without this you cam communicate with a mh NOID remote point but
cannot be mh yourself
- needs R6 RR into the DNS
- no packet overhead for data packets
- uses flow id plus next header values
- conceptually this is similar to an extension header to operate at
the shim layer
- new ICMPv6 packets for the handshake
- NOIDS walk through in presentation
SIM concepts
- 128 bit identifier, a hash of a public key, akin to HIP, created
autonomously
- Upper Layer Protocol uses these identifiers
- shim layer needs a context tag, and is seeded from the DNS
- AAAA records plus new SIM ID RR type to collect identifier
- In order to prevent redirection, the public key crypto scheme is
used, as per CGA in SEND WG. Not needed until locators change.
- Also uses an explicit extension header
- new packets for handshake
- protocol exchange walk through
CB64
- middle ground between NOID and SIM - IP addresses with 64bit hash
of a public key
- previously discussed in SEND and MobileV6
High Level choices:
- Is it beneficial to introduce a new IP space as in SIM/HIP
- Or use multiple addresses
- DNS for verification issues? vs public key crypto? or no
verification?
- Use of local locators?
Clarification questions:
* Do you assume symmetric routing in these models?
No.
* Do you assume DNSSEC in these models?
No - but use of DNSSEC would improve the security of the use of DNS
* For SIM you claim no PKI is required, but a new DNS RR is returned -
Is this a public key record?
No keys are stored in the DNS in this approach. Its a derivative
rather than the actual key. The trust in NDS in no change
* The threats work said "don't make things worse". Those protocols
are being secured right now. To what version of these protocols are
you referring to - secured or unsecured?
If introduced today, we don't want to make things worse than
today, or in the future.
General Discussion
==================
1. Cutoff date for Proposals?
Kurt Lindquist (chair): The issue is for how much longer do we keep on
seeing the same presentations. The cutoff for proposals to be
submitted as drafts for WG consideration is proposed by the chairs
to be year end.
Brian Carpenter (chair): Call for comment on this proposed rule
Keith Moore: Serious reservations for this call. Nothing is serious
enough in the proposals to be a 'real' solution. IN the past a late
proposal has been a drastic improvement with eager WG adoption. Its
premature to reduce the number of proposals.
Jim Bound: Process point: I've read the specs - I don't need to hear
this.
Matsataka Ohta: This is fine for my proposal, but no good for others
as it promotes a step-by-step approach. The NOID approach does not
address interaction with mobility, for example.
Brian Carpenter: The proposals so far are not ready for evaluation,
but I'm not willing to accept more - they are two different points.
I don't know any way to make things happen without deadlines. If no
deadline then we will never complete the proposal stage.
Erik Nordmark: The thing you want to avoid is new proposals that are
similar to previous proposals in all but name. But different ways of
doing things should not be cut off. Maybe look at diffs to current
proposals rather than complete proposals
Eliot Lear: 31 Dec is very close. If so then why not make the proposal
cut today?
Brian Carpenter: we are aware of one draft that did not make it.
Eliot Lear: Could you please include HIP is this set of proposals for
WG consideration?
Keith Moore: The scheduling concern is fine for understood problems.
But if the problem is not understood, then setting deadlines for
proposals is not a solution path
Christian Huitema: What concerns me is the focus on proposals. So far
there are complete architecture presentations, and no modular
approach has been presented so far. Maybe modularity of the solution
process would help. Some things are constant/generic - eg ingress
filtering, security. None of the solutions seen so far provide for
incremental deployment - none have a business model that drives
incremental deployment.
Brian Carpenter: This concept of a cutoff date for proposal is not
being accepted by the WG. Instead could we set a target date for
ideas to get ideas out so we avoid a situation where everything
arrives at a face-to-face meeting. Reasonable?
WG: silence and nods
Decision: Chairs to set a date for the submission of ideas regarding
approaches to multi-homing
2. Evaluation Criteria
Randy Bush: we need to consider what e2e connection setup, referrals
(passive ftp), both ends attempt simul connect. NOID appears to be
incompatible with local addressing or two-faced DNS - I'm not sure
that this is a bad thing
Kurt Lindquist: Remind the WG on desired properties of a solution (see
slide) How to pick a proposal? RFC 3582 is one tool to do so
Brian Carpenter: Some of these questions raised are missing in that
RFC - the WG may want use a longer list of criteria
Kurt Lindquist: At some point we still need to pick a solution - we'll
take this to the mailing list to discuss these in depth - more merit
may be an outcome of combining aspects of these proposals
Decision: Take the topic of evaluation criteria for WG to use to the
mailing list.
3. General Discussion of Proposals
Erik Nordmark: thinking about how referrals work is very important -
each approach is different. Technical differentiator. In NOID, The
extra 8 bytes uses the flow id on the proposal. If you believe that
the rewriting of the ID by the receiver is good, then some help in
the header to flag this permission would be good.
Brian Carpenter: If we go down the path of this solution we should
discuss the version number at some stage
Erik Nordmark: 2 faced DNS and local addresses. NOID says you get the
id info from the DNS. Added words suggesting what happens when you
get inconsistent answers from the DNS? Maybe you need a mechanisms
to exchange the info you received. Or maybe sprinkling in some
other security technique into this may be useful. This has not been
explored in any detail.
Matsataka Ohta: I like my own security requirement drafts. I have
objections to his draft. redirection attack. The other concern is
that the security analysis is complete.
Brian Carpenter: please distinguish between threat analysis and
solution
Tony Li: Our proposal ensure incremental deployment by allowing each
host to advertise its capabilities.
Ilijsch van Beijnum: There are proposals where you need to store info
in the DNS that are not there today. Proposals to allow systems to
interact before interaction. Both at the same time is not ok.
Keith Moore: Use of DNS - likely that DNS is part of any successful
proposal. DNS names are service names as well as host names. not
just host names. Rebinding to the DNS IP addr is a dubious
assumption. In practice DNS is not universally consistent. Assuming
that DNS is a good mechanism for addressing updates and changes is
not a good assumption.
Brian Carpenter: use of reverse DNS tree?
Keith Moore: That would be unwise.
Jim Bound: Did not understand the use of compression in the flow-id.
The SCTP protocol combined with NOID may well be the answer. I'd IKE
to propose a submission to the WG on SCTP + NOID.
Brian Carpenter: As SCTP is not TCP this would imply that there would
be no TCP in your approach
Jim Bound: I had in mind SCTP simulating / emulating TCP
Brian Carpenter: It would be nice if we had a draft on this.
Brian Carpenter: Erik is correct - the only case where things look
strange is where the flow-id is exported in a coarse-grained style.
Multiple TCP sessions using the same flow-id will cause all TCP
sessions to suffer the same mh fate
Christian Huitema: incremental deployment. In all the proposals you
have to assume a world in which IPv6 is already deployed. The m6
proposal is an add on to a deployed network. You need an immediate
benefit to yourself without requiring other sites to also upgrade.
i.e. one-armed mechanisms that require no change to the other end.
e.g. advertise >1 addresses in the DNS and let the other end choose.
Want to see a way to solve egress filtering to an other end that
cannot do the rewrite trick.
Tony Li: egress filtering is orthogonal to the rest of the issues
here. They can be applied to all the proposals see so far
Dave Crocker: Rarely, I agree with Keith Moore. Need to distinguish
between names as a name space and names as a query mechanism.
MAs also has incremental adoption, but Huitema defined incremental
adoption in a way that MAST is not. We don't have a common shared
sense for criteria and terminology. Incremental deployment
capability in not on criteria list. Other considerations emerging,
and there is more. Theory is any single proposal may be attack on
these criteria. We need to get clear what is important and what is
not to allow proponents to respond carefully.
Kurt Lindquist: The RFC lacks criteria - the WG's evaluation list
appears to be bigger than that listed in the RFC..
Brian Carpenter: This is an OPS working group - these are close to
operational questions.
Crocker: I hear what you said but don't understand it.
Ellwyn Davis: Wondering is we are transferring the problem from the
data to the control plane. Bootstrapping is a real issue here. It
need to be thought through.
Matsataka Ohta: I propose that all proposals should address issues
already contained in additional to the RFC careful analysis of
interaction with DNS. For example in NOID DNS appears, but nothing
is mention of DNS as a connectionless protocol using UDP. Section
about connectionless UDP is very strange. ok?
Keith Moore: coming up with more criteria in a solution - this is
good. But if you acknowledge that you are going to compromise in
selecting than you will need a lot of help in doing the compromising.
The discussion flows around renumbering, mobility, etc, and there is
a good chance of conflicting with other efforts
Matsataka Ohta: General feeling about design parameters; global
routing table size, number of prefixes. Can I have discussion?
Brian Carpenter: If we did not care about the number of prefixes we
would not have this discussion
Randy Bush: (channeling Margaret Wasserman) Isn't there a multi6
draft about requirements? Shouldn't this draft be tuned with this
discussion? What are the technical details of these proposals? The
HIP BOF did a good effort of comparisons
Brian Carpenter: I feel a need for a document for a new set of
considerations, need a volunteer for a draft
Sean McCleary: What is the expected number of per-host addresses in
each proposal and what would push this number upward. Concerned that
it may rise to several dozen - I am concerned if it gets to that
high point
Tony Li: All the proposals are 1 locator per immediate ISP. Not 1
locator per inbound path
Eliot Lear: does it matter how many identifier there are?
[Several]: no!
Margaret Wasserman: I heard Randy channel me. The issues I have are
referral (as per passive ftp) and simultaneous TCP connect attempts
from each end. Questions about NOID from this perspective. In NOID
when if A -> B and B -> A starts up at the same time, state on A
with flow ID requires 2 DNS lookups on B and the B -> A connect
attempt will be rejected in the meantime. Is this bad?
Erik Nordmark: this was an exercise left to the reader. The document
has not thought through this scenario in detail. The document talks
about state loss and re-establishment efforts. There is a risk of
ending up with 2 different contexts. It sounds like the same issue,
but not sure.
Margaret Wasserman: Have a problem when we completely separate the
locators as an ID. How do we know this has occurred. Do we always do
the 2 DNS lookups on a referral, or is there state.
Erik Nordmark: 2 reasons why this would not work. a) renumbering (long
time scale) b) short term (routing). a) deal with it - don't keep
these things around forever. Use the FQDN to consult the DNS. A
locator without the FQDN is pretty useless. And the DNS reverse
should fail in such a case. Referrals and failure simultaneous -
you can pass across the id. One approach is the other end to do the
2 DNS thing to retrieve the full set of locators, or the other end
could send off the full locator pool
Margaret Wasserman: does with work with 2-faced DNS?
Erik Nordmark: DNS inconsistencies in responses require you to come to
the minimum intersection of the two sets. I've been thinking of a
weaker mechanism with some sort of security and some sort of local
or global scope.
Brian Carpenter: reverse tree reliance?
Christian Huitema: This is not a good idea. A cyclic dependency is not
what you want. Today's reverse is populated with poor data to a
level of around 50%. Not a good idea to rely on this data.
Brian Carpenter: multi-homed DNS server?
Randy Bush: MH is a lot of hoops. They will get reverse DNS right if
its part of the necessary steps. The cyclic dependency is a
substantive point.
Keith Moore: The rev-DNS tree is an anachronism. There are many forms
of relationships in the reverse -> forward, and its not generally an
inverse of the forward lookup functions
Dave Crocker: domain names are many things. Any global consistent name
space requires a query service. Use a new one or a new one?
Randy Bush: put it in BGP!
Erik Nordmark: Careful not to create recursion here - need to be
careful to use a lookup for locators not identifiers. DNS has its
own way of doing that by listing the IP addresses of the name
servers. You don't need to use this solution to lookup DNS name
servers. I don't understand what the operational issues are. Its an
identifier, not a locator. The DNS should check, because things
will, just, fall apart. one more thing... mumble....
Matsataka Ohta: I don't want to change current operational practice.
When its necessary use DNS reverse, but not mandate it. I actually
proposed a way to use TCP options to pass locators which means DNS is
not necessary.
Christian Huitema: The DNS is used to acquire a set of locators if you
have a locator, and so conceptually you could ask a server, the
other is to ask your peer. If you ask you peer to get an answer that
is not dependant on a server
Erik Nordmark: the server is used as a verification to avoid certain
forms of DOS attacks.
Christian Huitema: I hear you. The attack you describe was an attribute
with mobile ipv6 - you do a 2 way handshake with the locator to
verify before use, and this defends against he attack.
Erik Nordmark: You could this with an exchange - its something to go
explore further
Randy Bush: what I think I heard from ohta-san the reverse is just
increasing your confidence. The cert exchange is just increasing your
confidence. But what's going to be different here?
Pekka Nikkander: We wanted to discuss the reverse DNS thing. A
identifier / locator split will break things. A fix that relies on
reverse DNS would be a little bit awkward.
Bruce Campbell: The DNS is distributed, but not reliable. Using DNS to
load a mh session is not always reliable. This is an instance of
middlebox attack
Perry Metgzer: True the DNS is not perfectly reliable, nor is IP.
Things work without the DNS already, such as nutella. Its
unfortunate that we are producing this hairy ball of
interdependencies, but it may be the only way.
Steve Bellovin: ALIAS BOF about hints - hints are good for
optimizations, but they are not reliable directives. As long as it
still works if you can't get to the DNS this is better.
Iljitsch van Beijnum: We've looking into the DNS for locators or
exchange. Another is to just go ahead with TCP and back off into
another address on failure, and only on failure. i.e. backoff into
this form of exchange
Christian Huitema: Privacy, and where to engage this mechanism. Many
of the slides think of IP security as a layer above the exchange of
locators, yet I can see why want to have a peer discussion but not
want intermediaries to know of this. If we do an exchange to move
traffic to other locators I'd like to do this with privacy. On the
one hand you want to keep the IPSEC session going but protect the
information about locators.
Dave Crocker: layering shown usage, not control channel
Keith Moore: Opposed to Perry's comment. Applications that do not
depend on the DNS exist - many of them. The generalization is
incorrect, and applications are a broad spectrum, not two types
generically.
Brian Carpenter: No consensus about the use of reverse DNS in these
approaches so far.
Margaret Wasserman: Use identifier or id rather weakly here. IP
addresses are used within hosts as well as externally
Erik Nordmark: Christian Huitema suggested control channel privacy -
this is a trade- off. I don't know if confidentiality for the
control channel is necessarily the right thing to do.
Perry Metzger: This may not add up to better security overall.
Architecturally - You need to name state. It can't be IP addresses.
DNS labels are a fixed point and work as a named state.
Christian Huitema: the point is that we shall not impose a position on
the trade- off on privacy. It should be clear that the solution
should not _mandate_ that you drop confidentiality. I should have
control of what I choose to disclose and this should be compatible
with the solution.
Erik Nordmark: I understand the mobility concern about disclosure of
location. This may be different between disclosure of mh state per
se. After all any connection discloses the current connection state
in any case.
Brian Carpenter: In a paranoid location you may deliberately move the
location to take this to a non-disclosed locator.
Margaret Wasserman: Why frag over NOID?
Erik Nordmark: Not NOID, thats SIM.
Margaret Wasserman: why should it be above?
Nordmark: The reason you have this flexible system you have the
potential risk that different frags do down different paths. If
reassembly is done BEFORE source rewrite reassembly is not possible.
Brian Carpenter: Bound said - SCTP-based draft on the table. Anyone
willing to get a HIP-based draft on the table?
Pekka Nikkander: This is an initial draft on this. I'm willing to work
on a draft on this as a more specific effort.
Brian Carpenter: Need a draft summarizing the criteria we've
discussed here.
Eliot Lear: I volunteer to write this up
Brian Carpenter: Each proposal should self-assess against criteria, as
proposed to WG assessment.
Brian Carpenter: 31 Dec did not get WG approval, but a rush of
proposal 2 weeks prior to next IETF is also tough. 'sometime in
January" is a strongly preferred option.
Brian Carpenter: Need to think about how to converge ('marry')
proposals into a WG proposal from a set of individual proposals.
Tony Li: A competition among proposals is a barrier to consensus and
rational choice. We should be working in problems and look at
salient features, solutions to each of those problems. They may not
be in dependant, but thats fine. 'your' vs 'mine' is destructive to
working together.
Erik Nordmark: What are the pieces: filtering and the right exist.
Hints from elements need more work. It may not be a fine cut, but it
has promise.
Brian Carpenter: maybe we can see similar components in each of the
solutions
Kurt Lindquist: the security analysis looks common
Matsataka Ohta: We need proposals of complete architectures.
Brian Carpenter: we are not quite ready to do that yet.
Dave Crocker: Working over IPv4 as well could be considered
Brian Carpenter: Next Steps: Eliot Lear to prepare a draft on criteria
analysis, Jim Bound a SCTP document,Pekka Nikkander to prepare a
HIP-based document, i-d publication of design team document,
complete gathering of ideas, prepare evaluation criteria as applied
to proposals, and then undertake functionality analysis with a view
to convergence of WG efforts.
WG session adjourned.