Subject: Re: MBone

From: "Kevin C. Almeroth" <[email-masked]>
Date: Fri, 13 Sep 2002 04:50:17 -0700 (PDT)

>>> First point:  not necessarily.

Not necessarily means there is an existance proof.  The point was
that there are more ways to snoop traffic than having access to a
router.

>>It only requires being on a non-IGMP'd switch or a hub; at that point, 
>>you can snoop the traffic and see any packet going to any multicast group.
>>
>>It's much harder to snoop UDP; for non-broadcast, you'd have to be 
>>in-line (on the wire, effectively) or on a hub. While hubs are becoming 
>>less common, they're often being replaced with cheaper non-IGMP-capable 
>>switches. Which means that they're still hubs, as far as multicast 
>>traffic is concerned.

Without a dobut you are right, though I think the degree of difference is
awful small.  Through hosts with root on switches or through wireless into
the mix and you are back to being roughly equivalent.

However, for any reasonable content provider the difference shouldn't 
matter.  If you have sensitive/valuable content, whether it is unicast 
or multicast, it should be protected.  To say that multicast isn't being 
used because there isn't security is a non-sequitor.

>>Alternately, if you're on a non-IGMP'd switch or a hub, and someone else 
>>on the LAN is a member of the group, then you don't have a 28-bit key. 
>>You can snoop and see the list of addresses in use, a much smaller set.
>>
>>Finally, there are rules that hint at how to use subsets of addresses 
>>for different uses (notably different scopes), e.g., RFC2365, a BCP. 
>>That makes finding the 'needle in the haystack' much easier, e.g., if 
>>you're hunting for teleconferencing, unless overrides are used, the 
>>space is 15 bits, not 28.

Better yet, try RFC3171.  Bottom-line:  there are weak links in the chain.
But, if those weak links weren't there, other links would be weak links,
and THOSE weak links would still be weak enough to require using encryption.
It just so happens that the weak multicast links are only a bit weaker than
the unicast links.  Understand that convoluted logic?  :-)

-Kevin

---

From: [email-masked]
Date: Fri, 13 Sep 2002 08:58:14 -0400

> the unicast links.  Understand that convoluted logic?  :-)

By the same logic, if the next-stronger links for multicast still require
crypto, and the *weak* multicast links are only a bit weaker than unicast,
then the next-stronger ones are probably stronger than unicast - therefor
unicast should be using crypto too. (Understand THAT convoluted logic? ;)

Oh wait.. the security-conscious *are* using crypto on unicast - there's
a reason things like 'ssh' are popular... :)
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: Joe Touch <[email-masked]>
Date: Fri, 13 Sep 2002 08:06:25 -0700

> the mix and you are back to being roughly equivalent.

Hosts with root can't snoop anything but broadcast UDP on switches
unless the switch is configurable; many switches aren't.

> used because there isn't security is a non-sequitor.

There certainly may be more immediate concerns (scalability, accounting,
etc.), but that doesn't mean security isn't a concern.

> the unicast links.  Understand that convoluted logic?  :-)

Not quite; as Valdis observes.

Multicast is necessarily a LOT weaker:

        1) I can get a copy of packets by normal operation
        (join a group). there is no equivalent for UDP,
        notably for paths that aren't shared.

        2) UDP has application, network, and tunnel encryption that
        is both widely deployed and widely used. there is
        no equivalent for multicast.

Joe

---

From: "Gary E. Miller" <[email-masked]>
Date: Mon, 23 Sep 2002 14:23:59 -0700 (PDT)

Yo Joe!

> unless the switch is configurable; many switches aren't.

root has no problem seeing adjacent UDP even on a switch.  Just overflow the
arp cache or poison it.

Here is a link to how it is done:
	http://dhar.homelinux.com/dhar/downloads/Sniffers.pdf

The dsniff package includes tools for this purpose:
	http://monkey.org/~dugsong/dsniff/

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
	[email-masked]  Tel:+1(541)382-8588 Fax: +1(541)382-8676

---

From: "Gary E. Miller" <[email-masked]>
Date: Mon, 23 Sep 2002 14:54:22 -0700 (PDT)

Yo Joe!

On Mon, 23 Sep 2002, Joe Touch wrote:

> > root has no problem seeing adjacent UDP even on a switch.  Just
> >overflow the arp cache or poison it.
>
> That all presumes the switch doesn't detect this as an attack and
> shutdown that link, which is an entirely reasonable reaction.

resonable yes, practical, no.

The only way I know to prevent this is to hard code the MACs on the
switch.  This is time consuming to install and to maintain.

Barring that, please name ONE switch, or cite ONE credible reference
source, where arpspoofing is prevented at the switch by any means short
of harcoding the MACs.

RGDS
GARY

---

From: [email-masked]
Date: Mon, 23 Sep 2002 18:12:56 -0400

> unless the switch is configurable; many switches aren't.

Unfortunately, this isn't actually true - unless you've nailed down the
switch with a hardwired MAC-address-per-port configuration, you can get it
to cough up other people's data.  The canonical "brute force" method is to
simply flood the poor switch's ARP cache and sniff the traffic while it's
learning.  Snooping around the various repositories of such tools would
find more subtle ways of doing it....
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: Matt Crawford <[email-masked]>
Date: Mon, 23 Sep 2002 17:58:21 -0500

> source, where arpspoofing is prevented at the switch by any means short

Never mind, even hard-coding the MACs to the right ports doesn't
solve the problem.  Eve on port X can keep up a steady stream of ARP
replies to Alice on port Y and Bob on port Z, telling each that the
MAC address corresponding to their intended peer is that of Eve's
machine.  It works even if Alice and Bob are both on port Y.

---

From: "Gary E. Miller" <[email-masked]>
Date: Mon, 23 Sep 2002 16:06:15 -0700 (PDT)

Yo Joe!

On Mon, 23 Sep 2002, Joe Touch wrote:

> PS - as I also raised on private email earlier, some ISPs definitely
> hardcode which MAC can attach to a port (i.e., they lock on the first
> one that gets there, and prevent subsequent ones until there's an
> override).
>
> Specific case: Santa Barbara, Cox ISP.

I will bet $20 that COX does it on the Cable modem and not the
switch.

"uncapping" cable modems to get around the MAC limit is getting
pretty common these days.  See:
	http://www.cablemodemhack.com/

RGDS
GARY

---

From: Robert Elz <[email-masked]>
Date: Tue, 24 Sep 2002 12:50:40 +0700

Date:        Mon, 23 Sep 2002 17:58:21 -0500
    From:        Matt Crawford <[email-masked]>
    Message-ID:  <[email-masked]>

  | Eve on port X can keep up a steady stream of ARP
  | replies to Alice on port Y and Bob on port Z, telling each that the
  | MAC address corresponding to their intended peer is that of Eve's
  | machine.  It works even if Alice and Bob are both on port Y.

But this one is visible at the end nodes, which makes it a stretch on
snooping...   All the end node needs to do is treat a gratuitous ARP
reply as a hint to send a new ARP request, instead of using it to replace
the ARP cache (don't most people do that these days?)

There's nothing Eve can do to prevent Alice from replying to Bob's ARP
query, so either Eve keeps quiet, and so doesn't get packets, or Eve
also replies, and Bob sees two different ARP replies - which is a sure
sign of something bogus happening (more like cannon fire announcing the
charge, than someone snooping on what is happening).

kre

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 Sep 2002 14:47:35 -0700

Using a switch doesn't ensure security, but using multicast basically
ensures promiscuity (since non-multicast capable switches are more common).

joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 Sep 2002 15:01:01 -0700

> switch.  This is time consuming to install and to maintain.

It's sufficient to have the switch detect high rates of change, or large
numbers of MAC addresses as an attack. That's practical enough.

> source, where arpspoofing is prevented at the switch by any means short

Practical != economical. Further, there are MACs which are hardcoded
(i.e. to prevent overwrite of MAC addresses).

What I said was that it was EASY to get at multicast, not that it wasn't
impossible to get at unicast.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 Sep 2002 15:51:18 -0700

> Gary E. Miller wrote:
...

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 Sep 2002 16:04:01 -0700

> machine.  It works even if Alice and Bob are both on port Y.

Now Eve has to guess 32 bits, which is de-facto harder than guessing a
multicast address of 28 bits.

Further, again, this assumes the switch complies. Some switches at ISPs
reject ARP traffic from the port altogether, generating it internally
instead.

Joe