LISP Device Recommended Filtering Guidelines

Introduction

The following guidelines are designed to aid site administrators who
want to provide access control for LISP devices (typically ITRs and
ETRs) that they deploy.  These recommendations are not designed to
replace the site security polices for hosts behind the LISP device,
and should be used in conjunction with filtering/access control of
the site.  These policies can be implemented as Infrastructure ACLs
on firewalls or upstream routers. At this time, it is not possible
to deploy these ACLs directly on the Ti box.

The following guidlines show rules for IPv4 only; IPv6 should, in
general, follow the similar policies.

The following figure provides the context for the filtering
guidelines.

                                   |--------|
     E  |-----|                    | upstrm |     //        //
  <--I--| xTR |--[*]------[*]------| rtr/fw |----//Internet//
     D  |-----|   R        ^       |------- |   //        //
                  L        |
      LISP        O        |
      SITE        C        |
                           |
                <=== INBOUND POLICY
                    OUTBOUND POLICY ===>

  * Note: INBOUND and OUTBOUND refer to the direction of traffic
    from the perspective of the external (RLOC) side of the LISP
    SITE. Thus, the INBOUND POLICY refers to packets from the
    Internet headed toward the xTR of the LISP SITE, and the
    OUTBOUND POLICY refers to packets leaving the xTR of the
    LISP SITE headed toward the Internet.

For xTRs using Map-Resolvers/Map-Servers

INBOUND POLICY:

For traffic INBOUND to the LISP site from the Internet (RLOC side),
certain packets must be permitted to reach the ETR.
These packets include:

  LISP Control Plane:
    permit udp, dst-port 4342, src-addr=any, dst-addr=ETR RLOC

  LISP Data Plane: 
    permit udp, dst-port 4341, src-addr=any, dst-addr=ETR RLOC

In addition, certain packets should be permitted to reach the
ETR. These packets include:

  LISP Managemnt Plane:
    permit tcp, dst-port 22 (ssh), src-addr=any, dst-addr=ETR RLOC
    permit icmp, src-addr=any, dst-addr=ETR RLOC   [note 1] 

Unless LISP-NAT is being used, no traffic should be directly
destined to the LISP site's EID addresses. Traffic destined to
LISP-site EIDs is always LISP-encapsulated and destined to the
ETR's RLOC(s).

OUTBOUND POLICY:

For traffic OUTBOUND from the LISP site toward the Internet,
certain packets must be permitted to leave the ITR.
These packets include:

  LISP Control Plane:
    permit udp, dport 4342, saddr=ITR RLOC, daddr=Map-Resolver
    permit udp, dport 4342, saddr=ITR RLOC, daddr=Map-Server(s)
    permit IPsec AH (proto 51), saddr=ITR RLOC, daddr=Map-Server(s)  

  LISP Data Plane: 
    permit udp, dport 4341, saddr=ITR-RLOC, daddr=any

  Non-LISP Data Plane: 
    permit IP=any, saddr=ITR EID Prefix, daddr=any   [note 2, 3] 

In addition, certain packets should be permitted to reach "any."
These packets include:

  LISP Managemnt Plane:
    permit tcp, dst-port 22 (ssh), src-addr=any, dst-addr=any
    permit icmp, src-addr=any, dst-addr=any   [note 1] 

Note 1: ICMP can be further constrained by limiting allowable
        types to: Type 8 (echo), Type 0 (echo-reply), Type 3
        (destination unreachable), and Type 11 (time exceeded).

Note 2: Covers non-LISP encapsulated traffic with source addresses
        of LISP site EIDs. Traffic destined to non-lisp sites is
        forwarded natively. Return is typically through a PTR.

Note 3: Explicit support on the upstream PE router may be required
        to allow for uRPF checks on traffic sourced from EID prefix
        space to succeed.

xTR directly connected the ALT

INBOUND POLICY:

These policies are the same as the above xTR example, except that
GRE must also be permitted since ETRs receive Map-Request packets
directly from the ALT over GRE tunnels.  In addition, the IPSEC AH
policy is not required for Map-Server Registration.

On ingress to the LISP site, certain packets must be permitted
to reach the ETR. These packets include:

  LISP Control Plane:
    permit udp, dst-port 4342, src-addr=any, dst-addr=ETR RLOC
    permit GRE (proto 47), saddr=ALT Router(s), daddr=ETR RLOC

  LISP Data Plane: 
    permit udp, dst-port 4341, src-addr=any, dst-addr=ETR RLOC

In addition, certain packets should be permitted to reach the
ETR. These packets include:

  LISP Managemnt Plane:
    permit tcp, dst-port 22 (ssh), src-addr=any, dst-addr=ETR RLOC
    permit icmp, src-addr=any, dst-addr=ETR RLOC   [note 1] 

Unless LISP-NAT is being used, no traffic should be directly
destined to the LISP site's EID addresses.  Traffic destined to
LISP-site EIDs is always LISP-encapsulated and destined to the
ETR's RLOC(s).

OUTBOUND POLICY:

These policies are the same as the above xTR example, except that

GRE must also be permitted since ITRs send Map-Request packets

directly to the ALT over GRE tunnels.  In addition, the policy is

not required to support Map-Server Registration.


When controlling Egress traffic from the LISP site, the policy

must permit the following packets:


  LISP Control Plane:

    permit udp, dport 4342, saddr=ITR RLOC, daddr=Map-Resolver

    permit GRE (proto 47), saddr=ITR-RLOC, daddr=ALT Router(s)


  LISP Data Plane: 

    permit udp, dport 4341, saddr=ITR-RLOC, daddr=any


  Non-LISP Data Plane: 

    permit IP=any, saddr=ITR EID Prefix, daddr=any   [note 2, 3] 


In addition, certain packets should be permitted to reach "any."

These packets include:


  LISP Managemnt Plane:

    permit tcp, dst-port 22 (ssh), src-addr=any, dst-addr=any

    permit icmp, src-addr=any, dst-addr=any   [note 1] 


Note 1: ICMP can be further constrained by limiting allowable

        types to: Type 8 (echo), Type 0 (echo-reply), Type 3

        (destination unreachable), and Type 11 (time exceeded).


Note 2: Covers non-LISP encapsulated traffic with source addresses

        of LISP site EIDs. Traffic destined to non-lisp sites is

        forwarded natively. Return is typically through a PTR.


Note 3: Explicit support on the upstream PE router may be

        required to allow for uRPF checks on traffic sourced

        from EID prefix space to succeed.



Last Update: 09.30.2009 by gschudel@cisco.com
 

Comments are closed.