Subject: BGP labels: label spaces

From: Eric Rosen <[email-masked]>
Date: Wed, 15 Dec 1999 14:23:33 -0500

I'm going to start  a couple of new threads to discuss  the issues that have
been raised re draft-ietf-mpls-bgp4-mpls-03.txt. 

With respect to the issue of  whether a platform label space or an interface
label space is to be used:

- In  general, when a  BGP speaker receives  a packet, it cannot  tell which
  other BGP speaker  was the last BGP speaker to  transmit the packet.  This
  does rule out the use of  a per-interface label space in general.  I think
  this  is  adequately  discussed   in  section  3.14  of  the  architecture
  document. 

- It is  not necessarily  true that  the use of  a per-platform  label space
  leads  to a  security hole.   If, for  example, you  never  accept labeled
  packets from  your network's "external" interfaces, and  you advertise all
  your  BGP-distributed  labels  via IBGP,  then  there  is  no way  for  an
  untrusted router to put a labeled packet into the network. 

  This condition can actually be  weakened significantly.  You don't need to
  refuse to accept  all labeled packets from external  interfaces.  You just
  need  to  make  sure that  any  labeled  packet  received on  an  external
  interface  has  a  top  label  which was  actually  distributed  out  that
  interface.   If a particular  interface is  considered "untrusted",  it is
  somewhat  unlikely that  there is  a system  out that  interface  which is
  part of one's own route reflector peer group.

  Then  you only  have  a security  problem  if you  have  both trusted  and
  untrusted systems out the same  interface.  (In this sense of "interface",
  different VCs on the same physical interface would be considered different
  interfaces.)   One  way to  avoid  the problem  is  simply  to avoid  this
  situation. 

I have  no problem with adding some  clarifying text along the  lines of the
above.  Beyond  that, I don't  think there is  any problem that needs  to be
solved.