Re: PI/metro/geo [Re: The state of IPv6 multihoming development]

[RJ Atkinson <rja@extremenetworks.com>]

On Tuesday, Nov 5, 2002, at 12:43 America/Montreal, Iljitsch van 
Beijnum wrote:

> On Tue, 5 Nov 2002, RJ Atkinson wrote:
>
> > >  My point is that becoming a man in the middle is
> > > not an easy thing to do in general.
> > 	My point is that it so easy to do that it is a common attack 
> > throughout
> > today's Internet.
> Can you point me to something that might convince me of this?
http://www.cert.org
http://www.cert.org/present/internet-security-trends/sld016.htm
	- general source of public data
http://www.cert.org/advisories/CA-1995-01.html
http://www.kb.cert.org/vuls/id/498440
	- specifically about TCP session hijacking by man-in-the-middle
RFC-1948
	- about the TCP sequence number predictability which facilitates
	  man-in-the-middle attacks on existing TCP sessions.
http://www.cert.org/advisories/CA-1996-21.html
	- about IP address forgeries (not man-in-the-middle)
http://www.kb.cert.org/vuls/id/684820
	- man-in-the middle vulnerability in SSHv1
http://josefsson.org/ktelnet/
http://www.kb.cert.org/vuls/id/774587
	- man-in-the-middle attack on Kerberos
http://www.research.att.com/~smb/papers/index.html#host
http://www.research.att.com/~smb/papers/ipext.ps
	- various papers by Bellovin on Internet security stuff,
	  including his early paper talking about TCP session hijacking
	  (among other issues)


> > Common enough that BGP added an MD5 authentication option
> > to prevent man-in-the-middle attacks on BGP.
> I've never heard of this actually happening.
I've seen it happen -- in fact I was one of the early victims,
which later caused various vendors to implement BGP MD5 in
routers.  Ask tli.

> Also, the MD5 option provides protection against spoofed RSTs.
The spoofed RSTs are PART of the man-in-the-middle attack.
There are things beyond forged RSTs that one can do, of course.

> > And common enough that we
> > need to really worry about with the current Internet.
> If man in the middle really is common we need to go down to layer 0 and
> implement some protection there. Crypto helps sell CPUs but a man in 
> the
> middle can still disrupt your traffic so crypto isn't enough.
AH/ESP are a pretty good protection against man-in-the-middle,
though expensive computationally.  IKE, however, needs to have
authenticated identities so that it sets up AH/ESP Security
Associations with the legitimate party not some stranger in
the middle.  SSL and some others provide varying levels of
protection.  Layer-0 isn't the answer, but not is it my point.

> > 	That aside, pretending these attacks are hard to implement or not
> > common on the deployed Internet is harmful because they are EASY to 
> > implement
> > and have been COMMONPLACE in the real world for several years now.
> Obviously we use different defenitions of these terms.
I'll bet at least one MIM attack is transiting any given major
ISP network as we speak, that is how common they are.  Ask CERT.
I'm told that scripts even exist for this stuff, so the attack does
not have to have clue (but have not myself sighted any sort of
attack scripts; not worth my time to try to find one).

> Performing the attack once you're in position is trivial. Tampering 
> with
> the infrastructure so you can receive and send packets while at the 
> same
> time the real destination/source is unable to, and doing this without
> being detected, is hard, except in some places at the edge of the
> network.
In some cases, one doesn't need to tamper with the infrastructure.  And
MOST network edges are vulnerable today.

But you've missed my point:  the point is that the identities we rely 
on today
are vulnerable to man-in-the-middle and we don't have global uniqueness 
of
identity today.  We do have probabilistic uniqueness with probabilities
much greater than 0 and visibility less than 1.  Similar 
probabilistically
unique identities should be enough going forward.

Ran