Subject: [rbridge] What should be the goal in terms of security?

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed Feb 2 06:52:34 2005

I certainly never thought of Rbridges as an idea for downgrading the network by replacing routers but as a way of upgrading bridges to get such benefits of "routing" as you can get while still avoiding the configuration penalties of IP routing. More security is better if you can get it without undue penalty but bridged security is adequate, in my opinion.

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
Sent: Wednesday, February 02, 2005 8:34 AM
To: 'Developing a hybrid router/bridge.'
Subject: [rbridge] What should be the goal in terms of security?

Hi all,

after all the discussion about ARP and flooding and so on, i guess that 
an important point should be to clearly define what is the goal of the 
rbridge solution in terms of security. I mean it seems to me that the 
security provided by a router and the security provided by a bridge are 
quite different. I mean, in arp, hijacking a link layer address seems 
to be an important vulnerability, since it may allow sniffing and 
spoofing any interface of the cloud. Besides, the potential DOS attakcs 
that may result because of broacasts used for discovery may be 
important. All this issues are not present in a routed network AFAICT.

So i guess that the first question is: an rbridge solution should 
provide the level of security of a bridged network or the level of 
security of a routed network?

If the goal is to replace routers by rbridges, i would say that the 
routed network security level is required....

any thoughts...?

marcelo

---

From: fltemplin at acm.org (Fred L. Templin)
Date: Wed Feb 2 11:04:37 2005

Joe Touch and I have been discussing off-list about a study
I have been involved with over the past few years which has
resulted in the following two Internet-Drafts:

  http://www.ietf.org/internet-drafts/draft-templin-ipvlx-01.txt
  http://www.ietf.org/internet-drafts/draft-templin-ipvlx-errata-05.txt

and an updated version that will obsolete both of these at:

  http://ipvlx.com/IPVLX.txt

The study proposes mechanisms and operational practices for
establishing virtual links between IP peer end nodes. The virtual
link can provide authentication (e.g., using Secure Neighbor
Discovery - SEND) and confidentiality (e.g., using IPSec). In
some cases, the virtual link can be extended all the way to the
end nodes but in other cases it may be desireable to terminate
the link at a router in the end node's network, e.g., to protect
people and assets from would-be attackers. (Both alternatives are
supported in the model proposed by the study.)

The study proposes IPv6 as the L3 protocol for end-node addressing
and IPv4 as the L2 protocol, i.e., IPv6-in-IPv4 tunneling, but it
could easily be extended to deal generically with IP-in-IP tunneling
(where "IP" could refer to any IP version). The study proposes special
nodes called: "IPvLX Gateways" that get involved in establishing and
providing transit switching for virtual links. These nodes exhibit
some of the same hybrid routing/bridging features proposed for Rbridges,
and can be deployed incrementally without requiring flag-day upgrades
of existing routers and bridges. In fact, IPvLX gateways need only
be deployed in the same locations that an IPv4 NAT would be deployed.

While the study presents a big-picture proposal for a next-generation
Internet architecture, it is also useful to consider the component
aspects seperately. In particular:

  1) Autoconfiguration - IPvLX nodes automatically configure
     themselves for operation with zero configuration.

  2) Encapsulation - the study proposes a special encapsulation in
     the L2 (IPv4) header to encode flow identification information.

  3) Link adaptation - the study proposes a link adaptation scheme
     used by virtual link endpoints to dynamically determine the
     best-fit L2 segment size (without packet loss) while presenting
     a uniform MTU to L3.

  4) Virtual link extension - the study proposes methods for
     establishing virtual links through Secure Neighbor Discovery
     and establishing soft state for flow switching in intermediate
     IPvLX gateways.

  5) Error handling - a method for relaying ICMPv4 error messages
     back to the IPvLX gateway at the near-end of a virtual link
     is proposed.

  6) Mobilitiy - aspects of IPvLX node mobility are discussed.

Although this study is now concluded, it is my sincere hope
that some/all of its aspects may be found useful for adoption
as work items for this group and that others will be interested
in helping to carry the work forward.

Please send any questions/comments,

Fred L. Templin
American Kestrel Consulting
[email-masked]