Re: [LinkSec] teleconf notes 4/15/03
Thanks for the feedback Norm,
Norman Finn wrote:
> Mats,
>
> You raise a very good question -- can bridges create tunnels through
> untrusted bridges in order to keep the network up in the face of
> compromised equipment? Protecting the .1Q tag is necessary, but not
> sufficient, to allow this.
>
> The problem is that 802.10 is *not* a true tunneling technology. In
> particular, the untrustworthy bridge will stop a BPDU whether it is
> encrypted or not, because an encrypted BPDU would still have the
> standard BPDU destination MAC address.
True. I think a bridge can be untrustworthy in several ways.
- It could behave arbitrarily badly: try to eavesdrop, modify,
insert, stop data, perform DoS by not complying to 802.something,
etc, etc
- It is "honest but curious", i.e. processes data as requested,
but tries to extract information (basically passive eavesdropping)
There is probably a wide spectra in between these two...
I guess a first thing to do is to agree on what sort of malicious
behavior we aim to protect against. Clearly, if a bridge plainly
refuses to co-operate, it seems little one can do, except to consider
it "down" as you say. In other cases of malicious behavior, I
am not sure we have to be that strict: we could (theoretically
at least) tunnel through it as mentioned.
>
> So, the trusted bridges must either allow the untrusted bridges to
> participate in the Layer 2 protocols such as RSTP, GMRP, and GVRP,
> or must somehow discover each others' presence in spite of the
> intervening untrusted bridges, and construct tunnels that will allow
> them to pass their Layer 2 control protocols (and data, of course)
> through the untrusted cloud. The first solution will take some
> considerable effort to analyze, but my first reaction is to dismiss
> it as a possibility. The second solution seems reasonable, but I'm
> not sure how it could be done except by manual configuration, plus
> it requires us to invent a new kind of L2-over-L2 tunneling mechanism.
Yes, "1" seems difficult. There any many problems of course. For
instance, when a bridge is "installed" it could be that we are 100%
sure that it is trusted, but that could change over time.
It could be that we know at time of first
power up of the bridge, that it does operate properly.
But maybe we are installing
it in a physical environment (e.g. a public hot-spot type of place)
were there is an evident risk that someone over time will have the
opportunity to insert a "probe" into the bridge to do eavesdropping.
In this case, an acceptable solution would be to always tunnel
through this bridge (perhaps this requires manually configuring its
neighbors?). As long as the bridge forwards data for us, we are happy
and can then feel reasonably safe.
>
> I have no opinion, yet, on whether the first documents produced by
> the group should or should not be required to accommodate intermediate
> untrusted bridges. Remember that another possibility is to treat the
> untrusted bridge and all the links to it as being down, and relying
> on other paths, which presumably will be present, to carry the data.
Yes, though there might be cases were there is a bridge that we
for some reason MUST pass through. The threat that we have seen
is e.g. a WLAN access point in a public place: it could be that
its the only way to get connectivity. If it stops forwarding
packets for us, it's likely detectable, but if it eavesdrops or
modifies, we may not notice until it's too late...
Best,
/Mats
>
> -- Norm
>
> Mats Näslund (EAB) wrote:
> >
> > Hi all,
> >
> > I have a question concerning the conclusions (I make) of the meeting
> > notes below. (My apologies for not being able to attend so far; the
> > time of day in combination with day of week makes it very difficult.)
> >
> > Allyn Romanow wrote:
> > >
> > > Discussion
> > > Bob - threats only to links themselves, bridges not protected
> > > threats to L2 structure
> > > if bridge is corrupted, it's not considered part of the relevant
> > > architecture
> >
> > I don't get this. If this is the assumption made, then won't it
> > be absolutley *necessary* to be able to "tunnel" the security
> > through such a corrupted bridge? This seems to contradict the
> > conclusion in the summary above (and elsewhere) that: "end to end
> > security through an arbitrary bridged topology is considered not
> > sufficiently understood to be undertaken at the current time".
> >
> > My point is that if there is a case when you might need to tunnel
> > one bridge, you might in other cases need to tunnel through N bridges,
> > which asymptotically means e2e.
> >
> > Moreover, refering to Norm's tutorial from Dallas, the last slide
> > states: "end-to-end security associations transported through bridges
> > must not authenticate the 802.1Q tag".
> >
> > Now, if there indeed could exist corrupt bridges as mentioned above
> > that are defined "out" of the relevant architecture, I feel very
> > worried about such a bridge messing with my 802.1Q tags... Thus,
> > bridges that *are* part of the relevant arch. SHOULD have the
> > option to e2e protcet 802.1Q tags that are important to them,
> > and could need to pass the corrupt bridge.
> >
> > Again, my aplogies if my confusion is caused by not being able
> > to attend the phone conf.
>