Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)
draft-ietf-ospf-2547-dnbit-04

Network Working Group                                      Eric C. Rosen
Internet Draft                                              Peter Psenak
Expiration Date: September 2004                      Cisco Systems, Inc.

                                                    Padma Pillay-Esnault
                                                  Juniper Networks, Inc.

                                                              March 2004

    Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs

                   draft-ietf-ospf-2547-dnbit-04.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document specifies a procedure that deals with a particular
   issue that may arise when a Service Provider (SP) provides "BGP/MPLS
   IP VPN" service to a customer, and the customer uses OSPFv2 to
   advertise its routes to the SP.  In this situation, a Customer Edge
   (CE) Router and a Provider Edge (PE) Router are OSPF peers, and
   customer routes are sent via OSPFv2 from the CE to the PE.  The
   customer routes are converted into BGP routes, and BGP carries them
   across the backbone to other PE routers.  The routes are then
   converted back to OSPF routes sent via OSPF to other CE routers.  As
   a result of converting the routes from OSPF to BGP and back to OSPF,
   some of the information needed to prevent loops may be lost.  A

Rosen, et al.                                                   [Page 1]



Internet Draft     draft-ietf-ospf-2547-dnbit-04.txt          March 2004

   procedure is needed to ensure that once a route is sent from a PE to
   a CE, the route will be ignored by any PE which receives it back from
   a CE.  This document specifies the necessary procedure, using one of
   the options bits in the LSA (Link State Advertisements) to indicate
   that an LSA has already been forwarded by a PE, and should be ignored
   by any other PEs that see it.

Table of Contents

    1        Specification of Requirements  ........................   2
    2        Introduction  .........................................   2
    3        Information Loss and Loops  ...........................   4
    4        Using the LSA Options to Prevent Loops  ...............   5
    5        Security Considerations  ..............................   5
    6        Acknowledgments  ......................................   6
    7        Authors' Addresses  ...................................   6
    8        Normative References  .................................   7
    9        Intellectual Property Statement  ......................   7
   10        Full Copyright Statement  .............................   7

1. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

2. Introduction

   [VPN] describes a method by which a Service Provider (SP) can use its
   IP backbone to provide an "IP VPN" service to customers.  In that
   sort of service, a customer's edge devices (CE devices) are connected
   to the provider's edge routers (PE routers).  Each CE device is in a
   single VPN.  Each PE device may attach to multiple CEs, of the same
   or of different VPNs.  A VPN thus consists of a set of "network
   segments" connected by the SP's backbone.

   A CE exchanges routes with a PE, using a routing protocol that is
   jointly agreed to by the customer and the SP.  The PE runs that
   routing protocol's decision process (i.e., performs the routing
   computation) to determine the set of IP address prefixes for which
   the following two conditions hold:

Rosen, et al.                                                   [Page 2]



Internet Draft     draft-ietf-ospf-2547-dnbit-04.txt          March 2004

     - each address prefix in the set can be reached via that CE

     - the path from that CE to each such address prefix does NOT
       include the SP backbone (i.e., does not include any PE routers).

   The PE routers which attach to a particular VPN redistribute routes
   to these address prefixes into BGP, so that they can use BGP to
   distribute the VPN's routes to each other.  BGP carries these routes
   in the "VPN-IPv4 address family", so that they are distinct from
   ordinary Internet routes.  The VPN-IPv4 address family also extends
   the IP addresses on the left so that address prefixes from two
   different VPNs are always distinct to BGP, even if both VPNs use the
   same piece of the private RFC1918 address space.  Thus routes from
   different VPNs can be carried by a single BGP instance, and can be
   stored in a common BGP table, without fear of conflict.

   If a PE router receives a particular VPN-IPv4 route via BGP, and if
   that PE is attached to a CE in the VPN to which the route belongs,
   then BGP's decision process may install that route in the BGP route
   table.  If so, the PE translates the route back into an IP route, and
   redistributes it to the routing protocol which is running on the link
   to that CE.

   This methodology provides a "peer model"; CE routers peer with PE
   routers, but CE routers at different sites do not peer with each
   other.

   If a VPN uses OSPFv2 as its internal routing protocol, it is not
   necessarily the case that the CE routers of that VPN use OSPFv2 to
   peer with the PE routers.  Each site in a VPN can use OSPFv2 as its
   intra-site routing protocol, while using, e.g., BGP or RIP to
   distribute routes to a PE router.  However, it is certainly
   convenient, when OSPFv2 is being used intra-site, to use it on the
   PE-CE link as well, and [VPN] explicitly allows this.  In this case,
   a PE will run a separate instance of OSPFv2 for each VPN which is
   attached to the PE; the PE will in general have multiple VPN-specific
   OSPFv2 routing tables.

   When OSPFv2 is used on a PE-CE link which belongs to a particular
   VPN, the PE router must redistribute to that VPN's OSPFv2 instance
   certain routes which have been installed in the BGP routing table.
   Similarly, a PE router must redistribute to BGP routes which have
   been installed in the VPN-specific OSPF routing tables.  Procedures
   for this are specified in [VPN-OSPF].

   The routes which are redistributed from BGP to OSPFv2 are advertised
   in LSAs that are originated by the PE.  The PE acts as an OSPF border
   router, advertising some of these routes in AS-external LSAs, and

Rosen, et al.                                                   [Page 3]



Internet Draft     draft-ietf-ospf-2547-dnbit-04.txt          March 2004

   some in summary LSAs, as specified in [VPN-OSPF].

   Similarly, when a PE router receives an LSA from a CE router, it runs
   the OSPF routing computation.  Any route that gets installed in the
   OSPF routing table must be translated into a VPN-IPv4 route and then
   redistributed into BGP.  BGP will then distribute these routes to the
   other PE routers.

3. Information Loss and Loops

   A PE, say PE1, may learn a route to a particular VPN-IPv4 address
   prefix via BGP.  This may cause it to generate a summary LSA or an
   AS-external LSA in which it reports that address prefix.  This LSA
   may then be distributed to a particular CE, say CE1.  The LSA may
   then be distributed throughout a particular OSPF area, reaching
   another CE, say CE2.  CE2 may then distribute the LSA to another PE,
   say PE2.

   As stated in the previous section, PE2 must run the OSPF routing
   computation to determine whether a particular address prefix,
   reported in an LSA from CE2, is reachable from CE2 via a path which
   does not include any PE router.  Unfortunately, there is no standard
   way to do this.  The OSPFv2 LSAs do not necessarily carry the
   information needed to enables PE2 to determine that the path to
   address prefix X in a particular LSA from CE2 is actually a path that
   includes, say, PE1.  If PE2 then leaks X into BGP as a VPN-IPv4
   route, then PE2 is violating one of the constraints for loop-freedom
   in BGP, viz., that routes learned from a particular BGP domain not be
   redistributed back into that BGP domain.  This could cause a routing
   loop to be created.

   It is therefore necessary to have a means by which an LSA may carry
   the information that a particular address prefix has been learned
   from a PE router.  Any PE router which receives an LSA with this
   information would omit the information in this LSA from its OSPF
   routing computation, and thus would not leak the information back
   into BGP.

   When a PE generates an AS-external LSA, it could use a distinct tag
   value to indicate that the LSA is carrying information about an
   address prefix for whom the path includes a PE router.  However, this
   method is not available in the case where the PE generates a Summary
   LSA.  Per [VPN-OSPF], each PE router must function as an OSPF area 0
   router.  If the PE-CE link is an area 0 link, then it is possible for
   the PE to receive, over that link, a summary LSA which originated at
   another PE router.  Thus we need some way of marking a summary LSA to

Rosen, et al.                                                   [Page 4]



Internet Draft     draft-ietf-ospf-2547-dnbit-04.txt          March 2004

   indicate that it is carrying information about a path via a PE
   router.

4. Using the LSA Options to Prevent Loops

   The high-order bit of the LSA Options field (a previously unused bit)
   is used to solve the problem described in the previous section.  We
   refer to this bit as the DN bit.  When a type 3, 5, or 7 LSA is sent
   from a PE to a CE, the DN bit MUST be set.  The DN bit MUST be clear
   in all other LSA types.

                     +-------------------------------------+
                     | DN | * | DC | EA | N/P | MC | E | * |
                     +-------------------------------------+

                            Options Field with DN Bit
                             (RFC 2328, Section A.2)

   When the PE receives, from a CE router, a type 3, 5, or 7 LSA with
   the DN bit set, the information from that LSA MUST NOT be used during
   the OSPF route calculation.  As a result, the LSA is not translated
   into a BGP route.  The DN bit MUST be ignored in all other LSA types.

   This prevents routes learned via BGP from being redistributed to BGP.
   (This restriction is analogous to the usual OSPF restriction that
   inter-area routes which are learned from area 0 are not passed back
   to area 0.)

   Note that the DN bit has no other effect on LSA handling.  In
   particular, an LSA with the DN bit set will be put in the topological
   database, aged, flooded, etc., just as if DN were not set.

5. Security Considerations

   An attacker may cause the DN bit to be set, in an LSA traveling from
   CE to PE, when the DN bit should really be clear.  This may cause the
   address prefixes mentioned in that LSA to be unreachable from other
   sites of the VPN.  Similarly, an attacker may cause the DN bit to be
   clear, in an LSA traveling in either direction, when the DN bit
   should really be set.  This may cause routing loops for traffic which
   is destined to the address prefixes mentioned in that LSA.

   These possibilities may be eliminated by using cryptographic

Rosen, et al.                                                   [Page 5]



Internet Draft     draft-ietf-ospf-2547-dnbit-04.txt          March 2004

   authentication as specified in section D of [OSPFv2].

6. Acknowledgments

   The idea of using the high-order options bit for this purpose is due
   to Derek Yeung. Thanks to Yakov Rekhter for his contribution to this
   work.  We also wish to thank Acee Lindem for his helpful comments.

7. Authors' Addresses

   Eric C. Rosen
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, MA 01719

   E-mail: erosen@cisco.com

   Peter Psenak
   Parc Pegasus,
   De Kleetlaan 6A
   1831 Diegem
   Belgium

   E-mail: ppsenak@cisco.com

   Padma Pillay-Esnault
   Juniper Networks
   1194 N. Mathilda Avenue
   Sunnyvale, CA 94089

   E-mail: padma@juniper.net

Rosen, et al.                                                   [Page 6]



Internet Draft     draft-ietf-ospf-2547-dnbit-04.txt          March 2004

8. Normative References

   [OSPFv2] "OSPF Version 2", RFC 2328, Moy, J., April 1998

   [VPN] "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-01.txt, Rosen,
   Rekhter, et. al., September 2003

   [VPN-OSPF] "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", draft-
   ietf-l3vpn-ospf-2547-01.txt, Rosen, Psenak, Pillay-Esnault, February
   2004

9. Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

10. Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78 and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,

Rosen, et al.                                                   [Page 7]



Internet Draft     draft-ietf-ospf-2547-dnbit-04.txt          March 2004

   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Rosen, et al.                                                   [Page 8]