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

From: "Tony Li" <[email-masked]>
Date: Mon, 4 Nov 2002 15:31:18 -0800

Tony,

|   > We happened to recently change
|   > providers at my company and, because we are behind a NAT 
|   system, found
|   > the change to be quite trivial.  Of course, we only needed to 
|   > renumber the
|   > NAT box.
|   
|   That will work for some companies with limited application 
|   needs, but
|   for others nat is a non-starter. 

Sorry, I should have been more clear.  No, I'm NOT trying to
sell NATv6.  

My point is that when the external locators are configured in
a very small number of places and internal addressing is independent
of external addressing, renumbering is very simple.  In 16+16,
I'd propose that the external locator be only in the border router.

|   Well, for the general case that one 'system' needs to 
|   include the border
|   router, dns, firewall, ids, partner access lists, etc...

Hmmm...  why?  The only thing that the border router does is
to add or remove the locators from the L3 header.  Access 
lists should be operating on the identifier, not the locator,
correct?

|   In fact we have an existence proof in both DNS & IEEE EUI that
|   inadvertent & intentional duplication happens. So those 
|   mechanisms can't
|   be used as 'globally unique' identifiers as they are. If we add some
|   cryptographic properties, we can probably improve that.

Ok, but do we need actual perfect uniqueness?  Or just 'pretty close'?
Operationally, 'pretty close' is a whole lot easier.

|   > I submit to you that if folks are unwilling to change to an
|   > architecture that scales, then IPv6 is already doomed.
|   
|   If the changes are contained to the routers, the timeframe 
|   is reduced
|   from 7 years to 3. In any case a drastic change will take 
|   two years to
|   get vendor shipments and another year for service providers 
|   to deploy. 

Well, if the changes are confined to the routers, then that
pretty much precludes transport changes and DNS changes.

I guess we're done.

|   > That is certainly true today.  However, there is no 
|   requirement for
|   > that.  Consider that host foo.cisco.com already has a globally 
|   > unique and fixed hostname.  We allocated this in a hierarchical
|   > fashion that requires no aggregation.  We simply do the same for
|   > the identifier space.
|   
|   That is the same argument that was used to structure the 
|   locator part
|   according to provider hierarchy ... ;)

Umm...  I don't see that at all.  But maybe I'm just not getting your
joke.

|   That aside, until we get DNSsec widely deployed there is 
|   nothing that
|   prevents someone from injecting foo.cisco.com into a remote 
|   part of the
|   tree. The only way we can consider a bit string to be a 
|   globally unique
|   identifier would be to have some cryptographic property 
|   that could be
|   checked in real time. I am not opposed to such a system 
|   being created,
|   but holding IPv6 multihoming hostage until it exists would be a
|   disservice to those who need expanded multihomed address space now.

Yes, someone could masquerade with someone else's identifier.
However, doing a lookup on the identifier should return the locators
for the correct host, not the imposter.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 4 Nov 2002 16:21:58 -0800

> I'd propose that the external locator be only in the border router.

I have looked, but can't find a reference to the 16+16 draft, please
send a pointer so I can get into the context.

> lists should be operating on the identifier, not the locator,

Once we figure out how to verify that the indetifier is really unique.

> Operationally, 'pretty close' is a whole lot easier.

For RFC3041 addresses, the argument is that they are 'very close' to
unique, but we still require backing that up with DAD to minimize
confusion when collisions do occur.

> pretty much precludes transport changes and DNS changes.

If a 5-10 year solution is what we really need, now is the time to
start. At the same time, I suspect we are a couple years from an IRTF
result that will take a few more to work through the IETF, so the
dev/deployment cycle can start. While that is working its way through
the system though, we need to find a way to fit an expanded set of
multihome sites into the existing mechanisms. 

My approach has been that we draw a line between those that need to be
in the global table for business/policy reasons, and those that are
looking for local alternate service. We aggregate the latter group
through exchanges, and simply eat the pain of the first group. This
becomes a self correcting situation when financial feedback is applied
to the number of prefixes that get injected into the global table. 

>  ...

We need a system for doing those lookups that scales without imposing
limitations on movement. 

Tony

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 4 Nov 2002 20:48:27 -0500

> Operationally, 'pretty close' is a whole lot easier.

We don't *have* perfect uniqueness today.  www.cnn.com is a set of 
hosts,
not a single host.  DNS names are NOT globally unique today.
Neither are IP addresses, thanks to NAT or other widgets (e.g. load
balancer in front of server farm).

Since we don't have it today, I don't see how demanding absolute 
uniqueness
of identifiers is a reasonable thing to demand.  And forged identifiers
are trivial today.  In a new system there could be (at least) a 
mechanism
for providing optional authentication of the identifier.

Ran

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 4 Nov 2002 18:37:16 -0800

RJ Atkinson wrote:
> of identifiers is a reasonable thing to demand.  

You get away without uniqueness today by bounding the scope of
uniqueness with a locator. If you explicitly remove that bounding
function by insisting that the locator is separable and mutable, you
make the problem of attributing security attributes to an identifier
more complex. 

> And forged 
> identifiers are trivial today.  

By closely associating the identifier with the locator, forgery that
actually results in a usable connection is traceable and
compartmentalized with natural trust boundaries. 

> In a new system there could 
> be (at least) a 
> mechanism

If the border router is going to use that identifier to look up the
current locator, the authentication component would be a requirement
prior to any modification of the locator table. This would also be a
requirement before updating any DNS entries. (I bring up that last point
because last week I was talking to Vixie about DNS trust boundaries and
one approach would be to allow record updates when the record matched
the source address of a node that had successfully completed the 3-way
TCP handshake.) 

Tony

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 5 Nov 2002 07:59:01 -0500

On Monday, Nov 4, 2002, at 21:37 America/Montreal, Tony Hain wrote:
> uniqueness with a locator.

This is absolutely not true with the examples I gave.

> compartmentalized with natural trust boundaries.

This is also not true today.   Forged IP addresses are not
compartmentalised today.  And if there is a NAT anywhere along
the path, the recipient has no real idea where the packet
originated (nor does the NAT, because it could have been forged
before reaching the NAT).  Forged domain names are quite
common in spam email.  So for both forms of identifier that
we commonly use today, there is no global uniquness, no guarantee
of tracability, and no compartmentalisation.

> prior to any modification of the locator table.

We don't authenticate DNS names today when using them to look up
the IPv6 address of the target.  We *should* in a perfect world,
but no one does because DNSsec is not deployed (and there are questions
of how deployable it is).

> This would also be a

Ah, so you consider man-in-the-middle attacks to not be part of your
threat model.  Well that at least explains part of your commentary
above -- we still disagree because I think man-in-the-middle attacks
are pretty commonplace.

My claim was narrow, neither IP addresses nor FQDNs are globally unique
today in practice.  You have not refuted that claim.  What we have today
is probabilistic uniqueness of identifiers.  Keeping that seems 
desirable
in a future identifier, but insisting on global uniqueness is 
excessive, IMHO.

Ran

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 5 Nov 2002 16:54:30 +0100 (CET)

> compartmentalised today.

Forging IP addresses is easy in one direction. But 1. receiving the
packets that are sent back and 2. shutting up the real destination
aren't as easy, but those are also necessary to successfully engage in
non-trivial communication.

> Forged domain names are quite common in spam email.

Just because you label your C4 "shaving cream" and the label doesn't
fall off doesn't mean you'll fool the airport scanners.

> the IPv6 address of the target.  We *should* in a perfect world,

Actually we shouldn't have to in a perfect world.  ;-)

> of how deployable it is).

If you use SSL there is no need for the DNS replies to be 100% reliable
anyway as forging DNS information just becomes a very elaborate DoS
attack.

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 5 Nov 2002 12:09:39 -0500

On Tuesday, Nov 5, 2002, at 10:54 America/Montreal, Iljitsch van 
> non-trivial communication.

TCP connection hijacking relies on this ability to perform a 
man-in-the-middle
attack.  It is a long-standing threat and it isn't that hard to engage 
in.
See papers by Bellovin and others dating back to maybe 1988 for more.

> anyway as forging DNS information just becomes a very elaborate DoS

SSL is not a general solution.  Consider UDP-based applications or
routing protocols such as OSPF -- neither of which is helped one iota
by SSL.

Ran

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 5 Nov 2002 18:21:10 +0100 (CET)

> TCP connection hijacking relies on this ability to perform a man-in-the-middle
> attack.  It is a long-standing threat and it isn't that hard to engage in.

This is like saying "locks don't provide much security if your opponent
has a copy of the key". My point is that becoming a man in the middle is
not an easy thing to do in general.

> routing protocols such as OSPF -- neither of which is helped one iota

True. OSPF isn't helped an iota by DNSSEC either, though.

It annoys me that "security people" are quick to scream everything is
insecure while in reality many of the attacks they claim are possible
are very hard to carry out. This is very counterproductive as many
people conclude that everything is always insecure so why bother trying
to do anything about it.

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 5 Nov 2002 12:30:25 -0500

On Tuesday, Nov 5, 2002, at 12:21 America/Montreal, Iljitsch van 
Beijnum wrote:
>  My point is that becoming a man in the middle is

	My point is that it so easy to do that it is a common attack throughout
today's Internet.  Common enough that there have been multiple CERT 
advisories
warning about it.  Common enough that BGP added an MD5 authentication 
option
to prevent man-in-the-middle attacks on BGP.  And common enough that we
need to really worry about with the current Internet.

> are very hard to carry out.

	Um.  I regularly deny being a "security person".

	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.

	I don't discuss implementation details of any attack ever, but I will
note that all the information needed to code up a man-in-the-middle 
attack
is available online and/or in published papers.

Ran

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 5 Nov 2002 18:43:09 +0100 (CET)

> today's Internet.

Can you point me to something that might convince me of this?

> 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. Also, the MD5 option
provides protection against spoofed RSTs.

> And common enough that we

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.

> 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.

> attack is available online and/or in published papers.

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.

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 5 Nov 2002 13:23:50 -0500

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

> 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)

> 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.

> 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.

> 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).

> being detected, is hard, except in some places at the edge of the

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