Subject: [rbridge] Getting rid of unnecessary and limiting check on TRILL-encapsulated frames?

From: Radia Perlman <[email-masked]>
Date: Fri, 04 Sep 2009 21:06:04 -0700

If there's still a chance for minor, mostly editorial changes...

In section 4.6.2, which is about how to handle receipt of a 
TRILL-encapsulated frame:

 >>  8. The port on which the frame was received is checked and the frame
 >>     discarded if there is no TRILL IS-IS adjacency on that port.

I'd like to delete that, since I don't think that check is necessary, and
I was reading a paper about an architecture where endnodes are smart
and have some sort of directory to look up the destination, so that
the endnode can do the TRILL encapsulation, which would work fine (as
long as we delete that extra check), and
might be more secure than having RBridges just learn where endnodes are.
And smart endnodes could coexist with endnodes and RBridges that work
the way we've always imagined it....anyway, I
just would like to get rid of the extra check, since I don't think it
adds anything, and it does preclude some flexibility that might be useful
for some applications.

There's another place with that check:

 >>4.6.2.4 Known Unicast TRILL Data Frames

 >>   The port on which the frame was received is checked and the frame
 >>   discarded if there is no TRILL IS-IS adjacency on that port.

Again, just deleting that sentence I think would be good.

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

---

From: Radia Perlman <[email-masked]>
Date: Sat, 05 Sep 2009 15:28:09 -0700

And another case where it might be useful for an endnode to do the TRILL 
encapsulation is so that a
management station (presumably an endnode) can communicate with an RBridge.

Radia

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 5 Sep 2009 20:51:42 -0400

A management station that just wants to use SNMP can just be a
management station. If it wants to get LSPs, etc., I would think it
might as well also be a full fledged RBridge that happens to have only
one adjacency...

Donald
=============================

On Sat, Sep 5, 2009 at 6:28 PM, Radia Perlman<[email-masked]> wrote:
>>  >>  8. The port on which the frame was received is checked and the frame
>>  >>     discarded if there is no TRILL IS-IS adjacency on that port.
>>
>>  >>4.6.2.4 Known Unicast TRILL Data Frames
>>
>>  >>   The port on which the frame was received is checked and the frame
>>  >>   discarded if there is no TRILL IS-IS adjacency on that port.
>>

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 8 Sep 2009 14:43:26 -0400

In looking at Section 4.6, I think I found another problem.

How to handle multiple ports on an RBridge that all connect to the
same link is, I believe, correctly described in Section 4.4.4.
However, the step-by-step frame processing text in Section 4.6 does
not correctly mirror Section 4.4.4. In particular, it only includes
some text for this special case for multicast and broadcast native
frames. In fact, some special treatment is needed in this case for all
native frames and for multi-destination TRILL data frames. (No special
treatment is needed for known unicast TRILL data frames as they will
only be accepted on one port in any case and no new special treatment
is needed for layer 2 or TRILL control frames.)

So, unless there is objection, I plan to change Section 4.6 to
correctly follow the provisions of Section 4.4.4.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: Eric Gray <[email-masked]>
Date: Fri, 11 Sep 2009 06:46:34 -0400

Radia,

	Sorry, but that doesn't make any sense.

	Management is typically (possibly exclusively) done using
IP.  As such, it would be the case that management would be done
by an IP station, which probably would also be an Ethernet end
station.  As such, it would be located at the "edge" of an
RBridge campus, and would presumably communicate either directly
with "adjacent" RBridges, or it's frames would be "ingressed" 
by an "adjacent" RBridge for delivery to a remote RBridge.

	There is nothing about this that requires a management
station to be able to TRILL-encapsulate frames.

	If someone wants to build an end-station that can do this,
then they can build a one port RBridge and there is nothing we,
or anyone, can do to stop them.

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
Sent: Saturday, September 05, 2009 6:28 PM
To: TRILL/RBridge Working Group
Subject: Re: [rbridge] Getting rid of unnecessary and limiting check on TRILL-encapsulated frames?

Radia

---

From: Radia Perlman <[email-masked]>
Date: Fri, 11 Sep 2009 10:25:38 -0700

The problem with managing via IP is that all the RBridges would need IP 
addresses. I guess that's
plausible without configuration because of DHCP, but in an environment 
where the TRILL
campus is broken, it
might be better to talk to something using lower level stuff. I believe 
SNMP can work over Ethernet.

But the real question is why do we need that check in the first place. 
If there aren't good reasons
for it, it's one less thing to do when forwarding a packet.

Radia

---

From: Eric Gray <[email-masked]>
Date: Fri, 11 Sep 2009 17:11:47 -0400

Radia,

	Is it possible that - if you forward RBridge/TRILL 
encapsulated frames that you don't know - for certain - come
from an RBridge you know about - you might get a persistent 
loop?  I certainly believe that it is something of a break
in the forwarding model if it is possible for an RBridge to 
even receive RBridge/TRILL encapsulated frames from an entity 
that is not peered with the receiving RBridge.

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, September 11, 2009 1:26 PM
To: Eric Gray
Cc: TRILL/RBridge Working Group
Subject: Re: [rbridge] Resend: Getting rid of unnecessary and limiting check on TRILL-encapsulated frames?
Importance: High

Radia

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 11 Sep 2009 14:53:23 -0700

> that is not peered with the receiving RBridge.

Wouldn't the Hop Count still prevent loops?

---

From: Radia Perlman <[email-masked]>
Date: Fri, 11 Sep 2009 16:32:03 -0700

Right. As Caitlin said...encapsulated packets have a hop count...also, 
an endnode
is initiating it, not forwarding it, so I don't see how it could cause a 
loop.

Radia

Caitlin Bestler wrote:
> Eric Gray wrote:
>> Radia,
>>
>>     Is it possible that - if you forward RBridge/TRILL encapsulated 
>> frames that you don't know - for certain - come
>> from an RBridge you know about - you might get a persistent loop?  I 
>> certainly believe that it is something of a break
>> in the forwarding model if it is possible for an RBridge to even 
>> receive RBridge/TRILL encapsulated frames from an entity that is not 
>> peered with the receiving RBridge.
>>
>

---

From: Eric Gray <[email-masked]>
Date: Fri, 11 Sep 2009 19:44:04 -0400

Caitlin/Radia,

Hop Count - like TTL - doesn't prevent loops, it just reduces
their severity (by limiting the impact of individual PDUs to
some finite number of hops).  

In this case, since we don't know the sender of the PDU, we 
have no firmer basis than dewy-eyed optimism to believe the
hop count will be set to a usefully limiting value.  

If we could be certain - for the case that Radia mentioned 
- that the sender was an end station, then we (maybe) would 
have some justification for believing no loop could occur.

But the fact is that - just because the question Radia had
asked was based on the possibility that the unknown sender 
could be an end station does not mean that is the only case 
we need to consider.

--
Eric

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 11 Sep 2009 20:51:02 -0700

> could be an end station does not mean that is the only case 

Those are certainly valid reasons why an RBridge might want to
drop encapsulated frames from unknown sources (specifically, that
they MAY do so).

But the real question is whether there is a justification for
stating that they MUST do so. The approach that Radia is presenting
is classic "Be liberal in what you accept". It is optimized to
be resilient to minor discovery snafus.

The argument for rejecting it is that if whomever is the true
source of this frame had done their job properly then the
problem would not exist at all, or they are an attacker.
In either case they should not be accomodated.

Now if there was an effective Denial of Service attack that
this would strategy would enable then rejecting the frame
would make sense. But this doesn't strike me as a very effective
attack. Simply limiting forgiveness to periods when the queue
depths were out of the Yellow or Red zones would short circuit
any DoS attack with this technique. So I'd lean towards being
liberal in what is accepted.

-- 
Caitlin Bestler
[email-masked] - http://www.asomi.com/CaitlinBestlerResume.html
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Eric Gray <[email-masked]>
Date: Wed, 16 Sep 2009 09:41:58 -0400

Caitlin,

	Sorry, but I do not understand your arguments.

	In particular, when you say "In either case they 
should not be accomodated" are you saying that the PDUs
they wish to forward will not be forwarded, or do you 
mean to say that the protocol does not need to worry 
about these cases?

--
Eric

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 16 Sep 2009 09:02:57 -0700

> mean to say that the protocol does not need to worry 

I was explaining my understanding of the rationale for
having a MUST NOT forward requirement. Basically, the
reasoning is that there is no identified need for these
frames to be forwarded that cannot be solved by having
implementers read the specs more carefully. Therefore,
*any* risk of even short-lived loops would not be
warranted.

However, the countering philosophy is one that has
served the Internet well: be liberal in what you accept.
In this specific case I believe it applies, because
removing the requirement does not impede the ability
of RBridges to later deal with any DoS attack that
is developed, but does allow the flexibility of
being tolerant of bring-up configuration issues.

To be specific, if there were any language in the
draft covering this I think it should be that these
frames MAY be forwarded. Just deleting the language
would have the same effect, so my minimalist side
would prefer that.

I would definitely be opposed to stating that these
frames MUST or SHOULD be forwarded, because as cited
in the above rationale, they shouldn't have existed
in the first place.

---

From: Eric Gray <[email-masked]>
Date: Wed, 16 Sep 2009 12:12:32 -0400

Caitlin,

	Forwarding is special, even in the "Postel" sense.  Being
conservative in what you send and liberal in what you receive is
a two-edged sword with both edges applying to forwarding.

	Perhaps a better decision model would be based on handling
litter.  Just because you think it is okay to pick it up, doesn't
mean I think it is okay to pass it along.  In this case, if your
implementation passes it along, the recipient is now missing the
bit of differentiation that you had because that implementation
will have received it from an RBridge it *does* know about.

--
Eric

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 16 Sep 2009 09:41:04 -0700

I agree,

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 16 Sep 2009 10:20:24 -0700

> will have received it from an RBridge it *does* know about.

I understand that rationale. It is the basis of most 802.1
enhancements and fundamental to all network-oriented security
(as opposed to endpoint driven). For example, an XYZ-capable
Bridge does not admit frames to a  controlled priority unless
the frames come from an End Station it knows of or another Bridge
that it knows is XYZ-capable. In this way any end station receiving
a frame on an XYZ-controlled priority knows something about the end
station that originated it and the bridges the frame traversed.

But exactly what information is being provided by the fact that a
frame is TRILL encapsulated? The end station does not see the
encapsulated frame, and I do not see how de-encapsulating is
impacted in any way.  A specific example of a malformed or
malicious frame that would cause damage would justify a MUST
NOT forward, but I have not thought of any.

Now, if a group of RBridges wanted to extend any given 802.1 cloud
then they would have to follow the same rules on priority admission.
But without such a special extension, the RBridge is merely adjacent
to two 802.1 XYZ clouds, and is the originator of the frame when it
forwards it. Just as a router, it would have to follow any rules
that applied to an end station participating in an 802.1 XYZ cloud.

---

From: Eric Gray <[email-masked]>
Date: Wed, 16 Sep 2009 13:32:31 -0400

Caitlin,

	IMO, I think you're focusing on the wrong information.  It is
not the fact that an item was TRILL encapsulated that is lost in 
transiting a supposed "ingress" RBridge, it is the fact that it was
received by the RBridge already TRILL-encapsulated from somewhere
unknown to that Rbridge.

	The significance of that information is that the there is an
apparent topological anomaly that is being hidden by the RBridge 
that initially forwarded the TRILL-encapsulated frame.  Since there
is no way to include this information in subsequent forwarding, the
initial RBridge ought not to be allowed to forward the questionable
frame.  Therefore, "MUST NOT forward" is the correct behavior.

--
Eric

---

From: Eric Gray <[email-masked]>
Date: Wed, 16 Sep 2009 13:35:55 -0400

Forwarded as there was an error in one address in the prior
mail.  Apologies if tyou receive 2 copies...
====================================================================

Caitlin,

--
Eric

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 16 Sep 2009 11:19:36 -0700

> frame.  Therefore, "MUST NOT forward" is the correct behavior.

That is a strong argument for "MUST NOT ignore the anomaly by
simply forwarding the frame". However, dropping the frame is
not the only method of resolving the anomaly. I see no reason
why the exact mechanism needs a MUST.

In my opinion the only justification for MUST DROP would be if
the non-dropped frame could cause further damage, and *any*
method of resolving the anomaly is acceptable (although
customers who buy RBridges are likely to have preferences).

---

From: Radia Perlman <[email-masked]>
Date: Wed, 16 Sep 2009 13:16:13 -0700

Given that it might be controversial to remove the check entirely (and 
have it as MUST NOT check),
I propose we make it optional, with a default. I also think we should 
clean up the wording in the
spec, because I think it is weird, in the shared media case where R1 has 
two neighbors: R2 (an IS-IS
adjacency) and E (an endnode), that (as I interpret the current 
wording), R1 will accept encapsulated
frames from E if R2 is up, but stop accepting them from E if R2 goes down.

 >>     discarded if there is no TRILL IS-IS adjacency on that port.

to something like:

An RBridge MAY choose to reject TRILL-encapsulated frames from a
neighbor that it does not have an IS-IS adjacency with. The default
behavior is that it will reject such frames, although it may
be configured to skip that check.

******
Note that by changing from "receiving from a port" to "receiving from
a neighbor" I'm attempting to say that R1 not only checks the port,
but the source MAC address in the outer header, to avoid the weird case
I mentioned above.

I also don't have strong opinions about which way the default should be,
but given that I was advocating getting rid of the check, I'm being politic
by having the default being to reject such frames. :-)

Radia

---

From: Eric Gray <[email-masked]>
Date: Thu, 17 Sep 2009 12:48:06 -0400

Radia,

	From the perspective of protocol specification, it is somewhat
incorrect to say "X MAY do 'p' (and) the default behavior is that X
does 'p'." 

	Normative use of MAY in the first part of the example above means 
that the ability to "do 'p'" is optional.  The second part of the same
example, however, implies that ability to "do 'p'" is mandatory, since
'p' is the default behavior.

	Similarly, it is not clear what "reject" means in a forwarding
context.

	I agree that changing "from a port" (which is ambiguous) to "from
a neighbor" is an improvement.

	Hence I would suggest the following alternative wording:

"By default, an RBridge MUST NOT forward TRILL-encapsulated frames from
a neighbor that it does not have an IS-IS adjacency with. RBridges MAY
be configured to allow forwarding of these frames in cases where it is
known that a non-peering device (such as an end-station) is configured
to originate TRILL-encapsulated frames that can be safely forwarded."

	It's conceivable that "that can be safely forwarded" is ambiguous, 
and I am okay with eliding that part of the above text.  However, doing
so may also result in a comment (from the IESG, for instance) that the
specification needs to be (at least somewhat) explicit about when it is
okay to allow this kind of forwarding to occur.

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, September 16, 2009 4:16 PM
To: Caitlin Bestler
Cc: Eric Gray; Group
Subject: Re: [rbridge] Resend: Getting rid of unnecessary and limiting check on TRILL-encapsulated frames?

to something like:

******

Radia

---

From: Radia Perlman <[email-masked]>
Date: Thu, 17 Sep 2009 13:24:36 -0700

---

From: Dinesh G Dutt <[email-masked]>
Date: Thu, 17 Sep 2009 14:03:44 -0700

I'm fine with Eric's wording too,

Dinesh

---

From: James Carlson <[email-masked]>
Date: Fri, 18 Sep 2009 07:13:10 -0400

>>> to originate TRILL-encapsulated frames that can be safely forwarded."

It looks good to me, too.

-- 
James Carlson         42.703N 71.076W         <[email-masked]>
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge