Subject: [rbridge] Trivial question about FCS in Figure 3 of current protocol draft

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Sat, 20 Oct 2007 21:39:07 -0700

Figure 3 (bottom of page 9) has "Ethernet FCS". Since there are two 
Ethernet headers
(inner and outer), wouldn't there be two Ethernet FCS's? Should the 
diagram simply
omit "Ethernet FCS" or put it twice? Or is it correct somehow and I'm 
not looking at it right,
or do we actually intend to omit the inner Ethernet frame's FCS?

Thanks,

Radia

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Sun, 21 Oct 2007 17:02:17 -0400

See Section 4.1.4.

The FCS is commonly something that's buried in the port hardware and
gets generated at the time of or just before frame transmission and
checked at the time of or just after receipt and sometimes doesn't exist
in the interior of a bridge/Rbridge.

Since Figures 3 and 7 say they are a frame as it appears on the wire,
which is what IETF protocol descriptions are normally interested in, one
and only one FCS should be shown.

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Sunday, October 21, 2007 12:39 AM
To: Developing a hybrid router/bridge.
Subject: [rbridge] Trivial question about FCS in Figure 3 of
currentprotocol draft

Thanks,

Radia
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: james.d.carlson at Sun.COM (James Carlson)
Date: Mon, 22 Oct 2007 12:09:52 -0400

> and only one FCS should be shown.

I'm not sure that the question or the answer are 'trivial' here.

In a regular (non-VLAN) bridge, the FCS is normally preserved
end-to-end, so that it protects the frame in transit from molestation
by intermediate bridges.  This is why RFC 3518 (PPP Bridging) contains
a LAN Frame Checksum Preservation feature.

With VLANs, this is no longer true, and corruption introduced by an
intermediate malfunctioning bridge was in fact the cause of a
significant network outage at Sun several years ago -- so I think it's
not a trivial matter to commit to non-preservation of FCS.

All that said, I agree with the current plan: there's a single
medium-dependent FCS, checked and regenerated at hop, and thus no
protection of the frame contents while resident in system memory of
one of the intermediate bridges.  Adding an option (sigh!) for
end-to-end preservation would be nice, but may well be fighting an
uphill battle in terms of functionality and compexity.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Mon, 22 Oct 2007 13:40:45 -0400

I agree it is not as simple as I made out.

Another strategy is to keep the FCS on admitting a frame and whenever
you delete, insert, or change anything in the frame during processing to
do a compensating adjustment to the FCS, then transmit this modified FCS
with the frame. This alternative to generating it from scratch when the
frame leaves the bridge/Rbridge would have a reasonable chance of
detecting something like memory corruption within the device.

But I don't think we should say anything about which strategy Rbridge
implementations use other than requiring them to send frames with
correct FCS values and discard received frames with bad FCS values. 

Thanks,
Donald

-----Original Message-----
From: James Carlson [mailto:james.d.carlson at Sun.COM] 
Sent: Monday, October 22, 2007 12:10 PM
To: Eastlake III Donald-LDE008
Cc: Radia Perlman; Developing a hybrid router/bridge.
Subject: Re: [rbridge] Trivial question about FCS in Figure 3 of
currentprotocol draft

---

From: james.d.carlson at sun.com (James Carlson)
Date: Mon, 22 Oct 2007 15:26:26 -0400

Eastlake III Donald-LDE008 writes:
> with the frame.

That's a tall order with insert or delete, though there seem to be
(encumbered) mechanisms available.  I suspect that most
implementations will simply recompute unless a suitable adjustment
algorithm is suggested as part of the final document.

> This alternative to generating it from scratch when the

Sure.  I doubt that we'll see this in practice, though, and I think we
need to be aware that what we are really endorsing here is breaking
the end-to-end CRC argument for Ethernet subnetworks.  That's not
necessarily a horrible thing, in as much as most VLAN-capable bridges
already do this today, but still a knowing choice.

> correct FCS values and discard received frames with bad FCS values. 

In as much as it affects the correctness of the bits on the wire, I
think mentioning the risks of the regeneration issue is in scope for
this document.  It's as much in-scope as it was to create an option to
_avoid_ the very same problem in RFC 3518.

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Mon, 22 Oct 2007 16:13:41 -0400

Well, it doesn't seem that different from the situation with 802.1Q
bridges inserting and deleting C and S tags or 802.1AE interfaces
inserting or removing security tags or whatever.

But I guess I don't see any problem with putting in a sentence about
this.

Thanks,
Donald

PS:  :-) I suppose people that are really worried about corruption or
tampering with data inside their Rbridges should use the as yet to be
specified security option of the as yet to be fully specified option
feature...

-----Original Message-----
From: James Carlson [mailto:james.d.carlson at sun.com] 
Sent: Monday, October 22, 2007 3:26 PM
To: Eastlake III Donald-LDE008
Cc: Developing a hybrid router/bridge.
Subject: RE: [rbridge] Trivial question about FCS in Figure 3 of
currentprotocol draft

---

From: james.d.carlson at sun.com (James Carlson)
Date: Mon, 22 Oct 2007 16:24:41 -0400

> inserting or removing security tags or whatever.

It's not.  That's exactly why I said:

  That's not necessarily a horrible thing, in as much as most
  VLAN-capable bridges already do this today, but still a knowing
  choice.

> But I guess I don't see any problem with putting in a sentence about

OK; thanks.

> specified security option of the as yet to be fully specified option

I know you have a smiley there, but the lingering concern is about
message integrity being compromised by inadvertent errors rather than
protection from some sort of active attack.  End-to-end preservation
of FCS does provide protection against simple blunders.  Regeneration
at each node does not.

I wouldn't have made as big a deal out of it if we hadn't had our own
frightening run-in with the problem.  We had a "switch" (bridge) that
enjoyed flipping bits every once in a while on large packets.  The
fact that it computed a new FCS on entry into the VLAN (addition of
802.1Q header) meant that the failure was hard to find and nasty in
character.

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Tue, 23 Oct 2007 17:14:27 -0400

Sorry, my smiley was in connection with the "not yet specified"ness, not
to say that corruption isn't a serious problem when it occurs. At
transit Rbridges, TRILL data frames can normally be transmitted
unchanged from how they are received, including the FCS, or with only a
change in VLAN (or possibly priority) for which the FCS adjustment
shouldn't be too hard.

Donald 

-----Original Message-----
From: James Carlson [mailto:james.d.carlson at sun.com] 
Sent: Monday, October 22, 2007 4:25 PM
To: Eastlake III Donald-LDE008
Cc: Developing a hybrid router/bridge.
Subject: RE: [rbridge] Trivial question about FCS in Figure 3 of
currentprotocol draft

OK; thanks.