[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ascii-formatted version of the multi6 minutes from IETF58 - please send me corrections
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thanks!
- - kurtis -
On tisdag, nov 25, 2003, at 07:13 Europe/Stockholm, Geoff Huston wrote:
> 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.
>
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2
iQA/AwUBP8L2z6arNKXTPFCVEQLTqgCgjnT8ODtnexc6FY8vDUFaV58WX0wAoJ9H
X1DVGhQZUAcNM6+i5bb1rXoA
=OqzA
-----END PGP SIGNATURE-----