RE: evaluation of draft-van-beijnum-multi6-odt-00.txt

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

Hi Iljistch,

Some questions about the security of this proposal.

I have tried to spot the security measures used in the draft and i fond
that:

in section 6 you say that:
    The ODT authentication information consists of a secret or
    semi-secret key that each side announces to its correspondent.

How is this key obtained? is the key that it is sent in step 2 of the
procedure described in section 8 (as a challenge)
Or is it another key

Then you say that this key can be protected using IPsec, but in this case
how is the IPSec SA established between two generic nodes on the internet
(where no previous interaction can be assumed)

Thanks, marcelo


> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Iljitsch van Beijnum
> Enviado el: jueves, 08 de enero de 2004 20:04
> Para: Multi6 List
> Asunto: evaluation of draft-van-beijnum-multi6-odt-00.txt
>
>
> This is a short evaluation of the draft I submitted earlier today
> against RFC 3582 and draft-lear-multi6-things-to-think-about-00.txt.
>
> (For those who can't wait: it's available at
> http://www.muada.com/drafts/draft-van-beijnum-multi6-odt-00.txt )
>
> 3.1.1 Redundancy
>
> Well, duh.  :-)
>
> 3.1.2 Load sharing
>
> Since the solution will generally only kick in when the initially
> chosen path no longer works, most load sharing depends on the initally
> chosen path. The protocol mandates interactions that show the
> characteristics of the new paths when those are negotiated so load
> sharing when the protocol is active should be reasonable. It is
> possible to support multiaddress transport protocols for really great
> load sharing.
>
> 3.1.3 Performance
>
> See 3.1.2. This goal is only partially met.
>
> 3.1.4 Policy
>
> Again, this mostly comes down to the initial choice.
>
> 3.1.5 Simplicity
>
> I think this goal is met if no IPsec is used.
>
> 3.1.6 Transport survivability
>
> Check.
>
> 3.1.7 Impact on DNS
>
> Check.
>
> 3.1.8 Packet filtering
>
> The current source address selection problem must be solved in order
> for sessions to be established in the first place. After that, the
> protocol will determine which address pairs work and which don't.
>
> 3.2.1 Scalability
>
> Check.
>
> 3.2.2 Impact on routers
>
> A new extension header must be parsed. Otherwise no impact.
>
> 3.2.3 Impact on hosts
>
> ODT is completely backward compatible with current IPv6 and IPv4,
> assuming the presence of the extension header doesn't create any
> problems. The additional functionality can be implemented in the host
> kernel or a middlebox.
>
> 3.2.4 Host-routing interaction
>
> None.
>
> 3.2.5 Operations and management
>
> Operations and management might be slightly more difficult because
> traffic flow becomes less predictable and it becomes harder or even
> impossible to determine which packets are part of the same session by
> looking at packets on the wire.
>
> 3.2.6 Cooperation between transit providers
>
> None needed.
>
> 3.2.7 Multiple solutions
>
> Additional ways to enable the creation of new sessions when the
> initally chosen address is unreachable and especially better address
> selection (both source and destination) are highly desirable in
> addition to this solution.
>
> 4 Security considerations
>
> Security was considered. When IPsec isn't used and an attacker can
> monitor the packet contents in the initial packets, the attacker can
> redirect traffic to addresses under her control. Whether this is a
> materially worse threat than threats that already exist on insecure
> links is debatable. The fact that data flows to/from unexpected
> addresses may violate site or application security policies.
>
> 2.1 Routing
>
> Routing isn't affected as the solution just makes use of the routing
> infrastructure without interacting with it in novel ways.
>
> 2.1.2.1 Mobility
>
> Mobility wasn't considered. However, this solution largely solves the
> same problem as mobility in a similar way. As such it would be strange
> to implement both on the same host.
>
> 2.2.1 Does your solution provide for a split between identifiers and
>        locators?
>
> That's one way to look at it, yes.
>
> 2.2.2 What is the lifetime of a binding from an identifier to a locator?
>
> Indefinite.
>
> 2.2.3 How is the binding updated?
>
> The multihoming sub-layer in the IP or transport layer initiates
> (re)negotiation of addresses when this is deemed appropriate.
>
>     Will transport connections remain up?
>
> Of course.
>
> 2.3.1 At what layer is your solution applied, and how?
>
> Between the network and transport layers.
>
>     Is it applied in every packet?  If so, what fields are used?
>
> Yes. The address fields. For TCP and UDP, the checksum.
>
> 2.3.2 Why is the layer you chose the correct one?
>
> Ask me again over beers some time.
>
> 2.3.3 Does your solution expand the size of an IP packet?
>
> Only during the negotiation phase, sometimes.
>
> 2.3.4 Do you change the way fragmenting is handled?
>
> No, except for middleboxes implementing the solution.
>
>     If you use a shim approach, do you fragment above or below the shim?
>
> The shim is applied after fragmentation as this is the only way to
> allow implementation in a middlebox.
>
>
> 2.3.5 Are there any changes to ICMP error semantics?
>
> No.
>
> 2.4.1 Please explain the relationship of your solution to DNS
>
> Nothing new here.
>
> 2.4.2 Please explain interactions with "2-faced" DNS
>
> The DNS must supply at least one working address to the host initiating
> the communication. What it does or doesn't do apart from this is of no
> relevance.
>
> 2.4.3 Does your solution require centralized registration?
>
> No.
>
> 2.4.4 Have you checked for DNS circular dependencies?
> 2.4.5 What if a DNS server itself is multihomed?
>
> Since the solution only kicks in when single homed operation is no
> longer possible, by definition applying this solution doesn't do any
> harm. However, using ODT with DNS introduces additional dynamics where
> they aren't desired without much benefit so this is discouraged.
>
> 2.4.6 What application/API changes are needed?
>
> Applications should try the full list of available addresses. See the
> draft for more information.
>
>     Will old code just work with the new mechanism?
>
> Yes.
>
> 2.4.7 Is this solution backward compatable with "old" IP version 6?
>
> Yes.
>
>     Does your solution impose requirements on non-multihomed/non-mobile
>     hosts?
>
> Single homed correspondents to multihomed hosts must implement the
> solution in order to achieve multihoming benefits for a session.
>
> 2.4.8 Is your solution backward compatable with IPv4?
>
> Yes.
>
>     How will your mechanism interact with 6to4 gateways and IPv4 hosts?
>
> It should be transparent. Additionally, it should be possible to rehome
> IPv4 sessions over IPv6 and vice versa.
>
> 2.4.9 How will your solution interact with other middleboxes?
>
>     What are the implications for firewalls?
>
> Firewalls must be positioned such that all packets are seen by them.
> This is of course at odds with the redundancy requirement.
>
>     What are the interactions with NAT?
>
> It isn't entirely impossible that the solution works with some NATs
> some of the time. Minor provisions have been made to allow a single
> homed system behind a NAT to communicate with a multihomed system.
>
>     What are the interactions with web caches?
>
> Unknown.
>
> 2.4.10 Are there any implications for scoped addressing?
>
> Since all addresses are validated before use, any failures that are the
> result of mixing addresses with different scopes should be non-fatal.
>
>     How does your mechanism interact with multicast?
>
> Unknown.
>
>     How does your solution interact with link-local addressing
>     How does your solution interact with Son-Of-Sitelocal (whatever that
>     will be)?
>
> Mixing of address scopes isn't likely to lead to useful results. Apart
> from that: no problem.
>
> 2.4.11 Are there any layer 2 implications to your proposal?
>
> No.
>
>     How will your solution handle referrals, such as those within FTP?
>
> No change. Referrals are likely to fail after a failover. A separate
> solution for smarter referrals is desirable.
>
>     Are you introducing a namespace that might involve mnemonics?
>
> No.
>
> 3. Security Considerations
>
>     How secure should a multi6 solution be?  This is a reasonable
>     question for each solution to answer.  The author opines that the
>     worst case should be no worse than what we have today.  However, any
>     additional risks should be clearly stated by the authors.
>     Considerable time should be spent on threat analysis.  Please see [4]
>     for more details.
>
> While redirection to an attacker's address is a new attack vector, I
> don't believe this is a big deal: with unmodified IPv4 or IPv6 over an
> insecure link, an attacker can observe and disrupt traffic today as
> well.
>
> Iljitsch
>
>