Re: [LinkSec] teleconf notes 4/15/03
Norm:
There are two ways to handle addressing in cryptographic security
protocols. IPsec ESP supports both, so the names that are used in RFC 2401
have been gaining wider recognition.
Tunnel Mode - there are two headers, one protected and one
unprotected. In this situation, the inner and outer addressing can be
completely disjoint.
Transport Mode - there is one header. and it is unprotected. In
this situation, one address space serves protected and unprotected devices.
As you know, MAC addresses do not map to the network topology as is the
case with IP addresses. There is a single address space. In the
development of 802.10 SDE, we discussed the possibility of header
encapsulation. We did not find any need for it. All of the things that
were needed could be accomplished without it.
802.10 SDE supports security associations in three configurations, and an
arbitrary number of non-SDE-aware bridges may be between the security
association end points in each case:
station-to-station
station-to-bridge
bridge-to-bridge
Untrustworthy communications devices in a communication path can always
disrupt secure communications. Denial of service attacks are especially
easy from such devices, and no security protocol can prevent them. The
BPDU destination MAC address provides an attacker an indication of some
PDUs that are targets for one denial of service attack. Even if these were
hidden in some manner, traffic analysis would allow the attacker to
discover the right PDUs with a reasonable likelihood of success.
So in the end, I do not see what tunnel mode vs transport mode has to do
with LinkSec.
Russ
>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.
>
>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.
>
>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.
>
>-- 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.