RE: Multihoming by IP Layer Address Rewriting (MILAR)

[Peter Tattam <peter@jazz-1.trumpet.com.au>]

On Wed, 5 Sep 2001, marcelo bagnulo wrote:

> 
> 
> > De: Peter Tattam [mailto:peter@jazz-1.trumpet.com.au]
> > Enviado el: miercoles, 05 de septiembre de 2001 4:07
> > On Wed, 5 Sep 2001, marcelo bagnulo wrote:
> >
> >
> > For the case where you only have a single starting address but
> > there exists
> > severtal alternative addresses and there is no way to find the
> > alternatives (no
> > DNS entries), you can only rely on routing infrastructure to tell
> > you the rest
> > of the addresses if the peer can't tell you.  This case would
> 
> Sorry, I think I do not understand, but doesn?t always the host knows which
> addresses have been asigned to their own interfaces? Perhaps not all of them
> are reachable  but this issue could be addressed with Router Renumbering and
> Router Advertisement mechanisms, deprecating unreachable addresses.

I'm talking about addresses of the peer.  If we have only one address for the
peer there's no way to find out it's alternative addresses if we rule out DNS.

> 
> > force routers to
> > get involved which I hoped one could avoid.
> >
> > It doesn't have to be a router that tells you this, just some third party
> > service like DNS or a reachability cache or somehing.
> >
> > I agree with the comments mad by Christian about DNS not being
> > the best vehicle
> > for this kind of information.
> >
> 
> I am not saying that the DNS is the best option, I am just saying that for
> almost the same price of the usual AAAA query, the DNS can provide an
> initial address set, that can be overwritten in case that the other end
> consider it necesary.
> 
> > Is it worth pursuing the reachability cache idea?
> 
> I find it interesting. I think that bragg draft proposed something related,
> and reachability information was comunicated through redundant information
> on the routing protocol. A similar mechanism  could be used to inform a host
> about which of their own addresses are reachable from the outside.

The information could be considered advisory and would eventually be confirmed
either way by the syn handshake.  The risks of spoofing do however increase if
such a cache we contaminated.  This risk would be roughly equivalent to that of
bogus DNS entries.  We have grown accustomed to some degree of trust level with
the DNS.

It all boils down to what level of security you are trying to achieve.

A level of security based on a DNS lookup of the address could be achievable
with such caches.

Anything more would require you to enter the IPSec arena to establish
authenticity of each end.  Not all applications need this level of security
though.

It's clear that there's not going to be a one size fits all solution.

MH solutions that require high availability and security will take lots of
resources to authenticate in comparison to quick & dirty schemes that rely on
DNS or something similar to seed the MH process.

If you can't contact directly any of the addresses you know to be authentic,
the authenticity of the connection can't be guaranteed and should be reported
as such to higher layers.

However once you get connected to an address you know to be valid additional
addresses can be immediately exchanged.  A man in the middle attack can still
take place, but this is no different to a single - single address connection.
Only IPSec can prevent that from happening, but not all connections need IPsec.

Hijacking could take place but only by a man in the middle controllign traffic
both ways. A man in the middle can do plenty of other nasty things so it's
probably academic whether a connection could get hijacked in this manner.

Peter

> Regards, marcelo
> 
> 

--
Peter R. Tattam                            peter@trumpet.com
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210