Subject: Re: [rbridge] Threat and security analysis?

From: kiravuo <[email-masked]>
Date: Tue, 01 Jun 2010 16:32:36 +0300

Hello,

I think that looking into the security aspects of TRILL would be time
well spent. If TRILL or some other similar technology gains popularity:

- Larger Ethernets will be built, as multiple links give more capacity
   to handle all traffic, including broadcasts.
- Larger corporate Ethernets will rely on VLAN for security. They may
   or may not have firewalls, too, but in many cases VLAN is considered
   enough.
- Innovative uses will be found for cheap RBridges, e.g. multihoming
   for SoHo customers or mobility solutions (TRILL over Ethernet over
   IP over ADSL/3G/whatever). This assumes that RBridges will be cheap,
   but if a RBridge is just added software to a switch, they should be
   cheap compared to performance benefits.

Some practical issues that could be discussed in the TRILL security
document:

- Effects of TRILL for monitoring and filtering (partially discussed in
   the RBridges procol security considerations), as deep packet
   inspection is likely to fail unless the inspecting device is aware of
   TRILL.
- Attacks against TRILL, such as double tagging (a known VLAN exploit),
   that could possibly be used to hop packets to different VLANs by
   sending a packet with [VLAN1 | TRILL data | VLAN2] tags (I am not
   sure if this works, it just seems possible).

If the doube tagging works, it means that TRILL is not just a
replacement for STP and Ethernet, since adding TRILL means that
methods used to prevent VLAN double tagging can fail with TRILL.

Timo Kiravuo
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 Jun 2010 07:07:28 -0700

Hi,

>    to handle all traffic, including broadcasts.

That is directly against the advice of the problem and applicability statement.
IMO, we do not need further guidance on why this is not appropriate.

>    or may not have firewalls, too, but in many cases VLAN is considered

TRILL didn't create VLANs; it is outside the scope of this WG to explain why
VLANs do not provide security.

>    cheap compared to performance benefits.

Can you explain why you think this will be the case? TRILL seems useful to
deploy within the SoHo (perhaps) or in the backend network, but connecting the
two provides no benefit AFAICT - TRILL can't overcome a physical bottleneck.

>    inspection is likely to fail unless the inspecting device is aware of

That's a single sentence, and already (IMO) sufficiently addressed in the
protocol doc. Yes, a security doc could reinforce that, but we need to find more
to say than just this.

> methods used to prevent VLAN double tagging can fail with TRILL.

First, it would be useful to explain why VLAN double-tagging is a significant
security concern. Once an attacker has a packet, they can copy and redirect it
anywhere in any protocol. How is this different in VLANs?

Joe

---

From: Jukka Manner <[email-masked]>
Date: Tue, 01 Jun 2010 21:02:22 +0300

Hi Joe, a few comments below.

cheers,
Jukka

> IMO, we do not need further guidance on why this is not appropriate.

JM: Depends on the definition of "larger". ;) Yet, now that the version 
1 spec is pretty much done, we could look into going beyond the 
limitations of bridged Ethernet. Of course this would need a recharter 
and people interested to go beyond the IEEE technologies.

> VLANs do not provide security.

JM: This statement just goes around the problem, "I didn't invent 
technology X, I just use it". It would be worthwhile to document the 
implications that arise from relying on technology defined by others. 
Such work would probably fit into some deployment guidelines.

> two provides no benefit AFAICT - TRILL can't overcome a physical bottleneck.

JM: There are operators and companies looking at the evolution of their 
networks, and how to build new ones. Here Ethernet-based technology, 
such as TRILL, is being evaluated by companies very seriously.

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 Jun 2010 12:28:20 -0700

Hi, Jukka,

> and people interested to go beyond the IEEE technologies.

The problem is that TRILL relies on ARP. Although TRILL increases the bandwidth,
it does nothing to address the limits of distance or number of endstations that
Ethernet ARP imposes. A solution to those that works for Ethernet would work for
TRILL, but they're independent - it would not have anything specifically to do
with TRILL.

> Such work would probably fit into some deployment guidelines.

A statement about the security issues of VLANs would be great - and have nothing
to do per se with TRILL. Sure, it would affect TRILL, since TRILL uses VLANs,
but that's it AFAICT.

TRILL's deployment guidelines are fairly simple in that regard - it should work
where Ethernets work, with Ethernet's limitations, EXCEPT to increase the
cross-section bandwidth capacity by enabling the use of multiple independent paths.

> such as TRILL, is being evaluated by companies very seriously.

Sure - but just putting TRILL in might get you a press release, but won't solve
the bottleneck that defines SoHo limitations. The key question is "what does
TRILL gain"?

Overall, you've pointed out that there is a need for an Ethernet security
analysis - of which there are many, though another might be useful - but that's
independent of TRILL. This WG isn't chartered - or IMO likely to be rechartered
- to solve every issue with Ethernets.

Joe

---

From: Eric Gray <[email-masked]>
Date: Tue, 1 Jun 2010 16:48:08 -0400

Joe/Timo,

First I agree with what Joe has said here.  But I would like to add a bit more.

If there is to be a security analysis document produced here in the IETF, by the
TRILL working group, it should focus on security relating to the use of IS-IS as
a control protocol for TRILL and the potential for security issues with the use
of the TRILL header.

Other potential security issues - such as security of TRILL encapsulated frames,
VLAN security, and other L2-related security concerns MUST be considered
strictly out of scope in this venue.

I believe it will not take much analysis of the use of IS-IS as a control protocol
for TRILL to demonstrate that this is a concern that is already dealt with in the
RFCs already written regarding the use of IS-IS in general.

Security analysis of the use of the TRILL header is a horse of a different color.
However, I cannot tell that any of the concerns Timo points out relate directly
to this area of concern.

To add to what Joe has already said on specific points below, I would have to
also say the following:

- Relative size of the target networks does not appear to be very relevant as a 
   security concern;

- Cost of deployed implementations also does not appear to be relevant to the
   issue of security concerns, because -
   - Given the feature-creep that occurred during TRILL specification, a
      belief that it is likely that cheap implementations of TRILL will emerge
      might be excessively naive and optimistic, unless it subsequently turns 
      out that a lot of features defined are not implemented in a significant 
      subset of implementations (note that many cost-influencing features 
      stem from the extent to which TRILL specification impacts the use of 
      VLANs), and
   - The notion that "cheap implementations" (that likely do not implement 
      many of the specified TRILL features) will implement security features 
      - while skipping many others - seems to be counter-intuitive;

- It never has been the responsibility of control or data-plane protocols to 
   make the process of deep-packet inspection easy (the easiest way to do
   that is to minimize the proliferation of data-plane protocols that a DPI 
   engine needs to deal with).

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Joe Touch [[email-masked]]
Sent: Tuesday, June 01, 2010 4:07 PM
To: kiravuo
Cc: [email-masked]
Subject: Re: [rbridge] Threat and security analysis?

Hi,

Joe

---

From: "Y.J. GU" <[email-masked]>
Date: Wed, 02 Jun 2010 10:29:15 +0800

Hi all,
I am reading Trill base protocol. I find it a bit difficult to understand some 
terms.
So if anyone can help to clarify the terms, I appreciated very much.

First is Outer.vlan, is it a copy of Inner.vlan? Or is it a designated vlan 
for transport between RBs, different from the value of Inner.vlan? What's the 
goal of the Outer.vlan?

Second is LINK. Is the LINK refers to a direct link between two adjacent RBs, 
or does the LINK involves more than 2 RBs along its way?

If an 802.1Q bridge exists on the way between RBs, shall a LINK interrupt at 
this Bridge, as I think this bridge can not understand Trill message used to 
designate link information.

The last one is Forwarder. What's a Forwarder, what's the relationship between 
Forwarder, Transit RB, DRB?

Sorry for asking such stupid questions, but I'm really confused.
Thank you for your help.

---

From: Radia Perlman <[email-masked]>
Date: Tue, 1 Jun 2010 20:03:31 -0700

These are indeed confusing points. They are explained in the spec, but
it's fine to ask. You can ask me offlist if you want, but I don't
think the people on the list will mind review of these concepts. And
hopefully after this short explanation, the portion of the spec where
these concepts are described will be clearer.

1) outer VLAN: It is *not* a copy of the inner VLAN. In fact, if all
links were pt-to-pt (no shared media) this field would not be
necessary at all. But if the link is a shared link containing bridges,
the customer might care about which VLAN is used for inter-RBridge
traffic.  Also, because of bridge configuration, some VLANs might be
partitioned on that link. So the outer VLAN is just to for
inter-RBridge traffic (e.g., Hellos, and forwarded encapsulated
traffic), and it can change on each hop.  For instance, if the path is
R1-R2-R3, and the link between R1 and R2 is configured to use VLAN A
for inter-RBridge traffic, and the link between R2 and R3 is
configured to use VLAN B, then the outer VLAN will be set to VLAN A
when R1 forwards to R2, and when R2 forwards to R3, R2 will set the
outer VLAN to VLAN B.

2) Link: It's a single hop, as seen by RBridges. So, what R1 and R2
think of as a link that connects them might actually be a bridged
link, and when R1 sends something to R2, it might get forwarded by
several bridges between R1 and R2.  A "link" in TRILL is similar to
the concept of an "IP subnet" in IP...something that appears to IP to
be a single link.

3) I don't understand your third question "> If an 802.1Q bridge
exists on the way between RBs, shall a LINK interrupt at
> designate link information."  However, guessing at your question, the answer is that the relation between RBridges and bridges is pretty much the same as between bridges and IP routers. Bridges just see the outer header and forward.

4) "Forwarder": The original design of TRILL had just a single RBridge
on a link that encapsulates/decapsulates traffic. The WG wanted to
allow load splitting of this function, so that not all traffic to/from
the link had to go through one RBridge. It is possible to load split
based on VLAN. So, if RB1, RB2 and RB3 are all on the same link, it is
possible for RB1 to be the one that encapsulates/decapsulates one set
of VLANs, say {A, G, H}, and RB2 to be in charge of
encapsulating/decapsulating packets with a different set of VLANs, say
{B, C, Q}, and RB3 to be in charge of another set, say VLAN Y.  The
way TRILL makes sure that only one RBridge is
encapsulating/decapsulating a particular VLAN is that the Designated
RBridge (the one that wins the election) is allowed to delegate some
set of VLANs to other RBridges on the link.

I hope that helps...

Radia

---

From: Timo Kiravuo <[email-masked]>
Date: Wed, 02 Jun 2010 12:41:46 +0300

Hi,

> IMO, we do not need further guidance on why this is not appropriate.

Well, I think that when developing a new technology, it is basic 
responsibility to think that the technology might become popular and 
think about the consequences. If something works and gets into use, it 
will be also mis-applied. At least I would be happier if there is a 
document that says "If you do this, it will blow up in this manner" 
instead of just saying "you can do this and anything else is undefined".

I am not implying that all possible scenarios should be studied, but at 
least known issues should be revealed and warned about.

> VLANs do not provide security.

Yes, but TRILL is used in conjunction with VLANs and the changes to 
security should be in the scope.

> two provides no benefit AFAICT - TRILL can't overcome a physical bottleneck.

The purpose of TRILL is to make Ethernets more efficient. However as a 
side effect is also provides multi-homing.

SoHo networks are commonly behind one ADSL/cable modem link, but would 
like redundancy, like 3G or Flash/OFDM wireless backup (I know 
installations like this). However switchover means changing IP 
addresses, at least the public address of a NAT.

Now an operator might recognize a business case here, sell a router that 
will keep your IP addresses same. And that operator might use some 
traditional routing protocol, or decide to run TRILL, since they are 
running TRILL in their internal network already and they might be 
running Ethernet to the customer anyways. And TRILL is more suitable 
than STP as it includes IS-IS that has link costs.

I am not saying that running TRILL to the customer is the best or 
smartest solution, but I am saying that it might some day appear to make 
sense to somebody. For that reason it might be a good thing to spend a 
little bit of time today and discuss it and other obvious issues, 
instead of letting somebody else fall flat on their face later.

> anywhere in any protocol. How is this different in VLANs?

VLAN double tagging or double encapsulation is a method to inject 
packets to other VLAN segments. Brief googling brought up a Cisco 
document describing the problem and solution: 
http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml#wp39211

My point is that when the existing network is set up to clear the VLAN 
tags on ingress to VLAN trunk, TRILL header will hide the VLAN tag and 
it will be tunneled through the network. Now TRILL also processes VLAN 
tags, but will it be possible to send a frame with two VLAN tags, have 
TRILL process the outer, but ignore the second tag and then have the 
second tag activate at some other point of the network? I have not 
managed to analyze the protocol well enough to understand if this is 
possible or not, but I am willing to study this and other similar issues.

The Spanning Tree Protocol does not tunnel packets, but both VLAN and 
TRILL do and since VLANs are used to separate security domains, 
introducing TRILL has security implications.

Timo Kiravuo

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Jun 2010 08:48:29 -0700

Hi, Timo,

I think Eric and I have stated what we believe to be the limits of a security
analysis of TRILL.

> instead of just saying "you can do this and anything else is undefined".

The problem and appplicability statement already indicates why we chose not to
apply TRILL to address scale in distance or the number of nodes. This is no
different from how Ethernet blows up under those conditions. There's not much
more to say.

> security should be in the scope.

Changes, yes, but that's all...

> than STP as it includes IS-IS that has link costs.

This is a quite arcane situation, and much more easily solved with a VPN than
TRILL.

> sense to somebody....

Anyone who thinks this is a good idea is as likely to not read or actively
ignore advice. The universe of what NOT to do is infinite, and we do not have
the resources to address them all.

> second tag activate at some other point of the network?

In your example, IF there is a device that checks double VLAN tags, it should
have done so before TRILL encapsulates the message. I.e., filtering is done on
ingress. If that's how it's implemented, it'll work fine with TRILL. If that's
not how it's implemented, there are numerous ways it won't work anyway.

Again, this is a case where TRILL doesn't introduce anything new.

> introducing TRILL has security implications.

We have already discussed how the outer and inner VLANs are related, and the
security issues therein. Yes, a bad implementation can ignore those rules, but
that has nothing to do with double tagging or double encapsulation.

Joe

---

From: Jukka Manner <[email-masked]>
Date: Wed, 02 Jun 2010 21:42:08 +0300

Hi Joe, and others,

I have two follow-up questions:

a) Is there interest to look beyond the implied limitations? Even if the 
current protocol and architecture have the limitations that come from 
the legacy, it doesn't mean that nothing could be done about them.

b) I believe there was some interest in deployment guidelines, or is 
this also something people believe can be solved by saying "same stuff 
as for bridged Ethernets"?

Jukka

-- 
Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+470 22481
Aalto University                  Mobile: +358+(0)50+5112973
Department of Communications      Fax:    +358+(0)9+470 22474
and Networking (Comnet)           Office: G320a (Otakaari 5A)
P.O. Box 13000, FIN-00076 Aalto   E-mail: [email-masked]
Finland                           www.netlab.hut.fi/~jmanner/
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Jun 2010 12:48:52 -0700

Hi, Jukka,

> the legacy, it doesn't mean that nothing could be done about them.

I believe the current WG goals focus on documenting the initial specs (done) and
now documenting some extensions/optimizations of those specs.

It is probably well within scope to document the limitations of current
approaches, as is already required, e.g., in the Security Considerations of our
specs. Limitations based on issues that are outside TRILL, e.g., limits due
primarily to independent issues with IS-IS, Ethernet, or VLANs are outside the
scope of this WG. They might be of interest to other WGs in the IETF, or to the
IEEE.

The key is to show a linkage with how TRILL uses these components to present a
unique issue, or to show concerns with TRILL components themselves.

> as for bridged Ethernets"?

Anything that is *other* than "same as for bridged Ethernets" would be useful.
Anything that is equally true for bridged Ethernets would be out of scope, AFAICT.

Joe

---

From: Eric Gray <[email-masked]>
Date: Wed, 2 Jun 2010 17:00:35 -0400

Timo,

Probably there is a disconnect here, because you're asking if we should include
some new work that is ill-defined.  Perhaps the right answer would be for you 
to write an Internet Draft, post it and try discussing it at the next IETF meeting.

As Joe said, he and I have tried to refine what might be reasonably covered in
a security analysis in the TRILL working group.  My reason for trying to do this
(and I suspect at least part of Joe's reasoning as well) is that we need to limit 
the scope of new work to something that makes sense in the larger context.

For example, when you say "known issues should be revealed and warned
about", this is hard to separate from the thing you earlier said you were not
implying ("that all possible scenarios should be studied").  What exactly do
you have in mind when you say "known issues"?  If you do not have specific
issues in mind, how do you propose we discover them if we do not study all
possible scenarios?

Also, we're all adults, and none of us need newly assigned responsibilities from
people who are not offering to pay us to accept them.  From where does this
"basic responsibility" you mention derive?  If an inventor invents a better mouse
trap, he or she hopes the world will beat a path to their door, but their is no
obligation (that I am aware of) on the inventor to consider the consequences
to the world population of mice if their hopes are gratified and the new trap is
an immense success.

But you apparently feel that the inventor has some resposibility to consider also
what might happen if the new trap is used for cock-roaches or squirrels as well.
Sorry, but I do not follow the logic, and I feel that we need to scope this ambition
to some set of better defined tasks and responsibilities.

On the other hand, if you are indicating that you might be interested in doing
this sort of work, you are certainly welcome to start it and see if there is some
interest in your preliminary results.  But - part of what Joe and I have been saying
- is that you need to take the right pieces to the right places.  And - if you think 
the TRILL working group is the right place for some of the pieces - you need to
be prepared to justify your thinking.  If the work is already being done somewhere
else, or is properly the responsibility of another SDO, then we don't need to take
it on in this working group as well.

--
Eric
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Timo Kiravuo [[email-masked]]
Sent: Wednesday, June 02, 2010 11:41 AM
To: [email-masked]
Subject: Re: [rbridge] Threat and security analysis?

Hi,

Timo Kiravuo

---

From: "Y.J. GU" <[email-masked]>
Date: Thu, 03 Jun 2010 13:15:23 +0800

Hi Radia,
So glad to receive your reply in such a short time. Your answer helps me to 
understand Trill much better.

-----Original Message-----
From: Radia Perlman [mailto:[email-masked]]
Sent: Wednesday, June 02, 2010 11:04 AM
To: Y.J. GU
Cc: [email-masked]
Subject: Re: [rbridge] Who can help to answer some questions?

> designate link information."  However, guessing at your question, the answer 
> is that the relation between RBridges and bridges is pretty much the same as 
> between bridges and IP routers. Bridges just see the outer header and 
> forward.

I hope that helps...

Radia

---

From: Joe Touch <[email-masked]>
Date: Mon, 07 Jun 2010 08:36:27 -0700

Hi, Timo,

Before spending too much time on a draft, it's useful to get coordinate its
scope and focus. In this case, so far I haven't seen a specific reason for a
*TRILL* security document - most of the feedback so far has been that the
existing documents already address the key issues, and that many other concerns
would be outside the scope of either the TRILL WG or the IETF as a whole.

I.e., IMO, IDs are useful to kickoff discussions whose details need to be seen;
in this case, the scope and focus are the issue, and that should be resolved in
emails first.

Joe

Timo Kiravuo wrote:
> On 3.6.2010 0:00, Eric Gray wrote:
> ...
> I apologize for being a newbie. I was not trying to dump this to other 
> people, but to see if anybody else was interested. I'll try to collect 
> my thoughts together and see what to do, possibly write a draft.
> 
> Timo Kiravuo

---

From: Timo Kiravuo <[email-masked]>
Date: Mon, 07 Jun 2010 16:51:51 +0300

...

Timo Kiravuo