Subject: Re: [lisp] Issue Title (number): LISP and uRPF and Anonomous Tunneling(58)

From: Yakov Rekhter <[email-masked]>
Date: Mon, 14 Feb 2011 11:57:22 -0800

Darrel,

> Issue Title (number): LISP and uRPF and Anonomous Tunneling(58)
> Draft Section: 12
> Issue Description: General LISP Security issues.
> Comments:
> 
> 
> There are many comments above that relate to security. Grep for
> "security" or "attack". Other possible issues that come to mind that
> should be explored here are whether LISP breaks RPF, and whether the
> ubiquitous tunneling infrastructure could be reused as a botnet
> anonymization service.
> 
> Response:
> 
> Dear Yakov-
> 
> Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors
> have reviewed your comments but are unclear on the nature of the issue. Can
> you please elaborate and clarify your concerns? 

I'd like the draft to explicitly spell out how uRPF will work in
the presence of LISP.

I also would like the draft to explicitly spell out whether the
ubiquitous tunneling infrastructure used by LISP could be reused
as a botnet anonymization service, and if yes, then what are the
mechanism(s) to prevent this from happening.

Yakov.

---

From: Darrel Lewis <[email-masked]>
Date: Mon, 14 Feb 2011 15:43:30 -0800

> I'd like the draft to explicitly spell out how uRPF will work in

LISP message handling and the impact of expected strict-uRPF behavior on LISP control messages is covered in section 6.1.5, which says:

 When sending a Map-Reply message, the destination address is copied
   from the one of the ITR-RLOC fields from the Map-Request.  The ETR
   can choose a locator address from one of the address families it
   supports.  For Data-Probes, the destination address of the Map-Reply
   is copied from the source address of the Data-Probe message which is
   invoking the reply.  The source address of the Map-Reply is one of
   the local locator addresses listed in the locator-set of any mapping
   record in the message and SHOULD be chosen to allow uRPF checks to
   succeed in the upstream service provider.  The destination port of a
   Map-Reply message is copied from the source port of the Map-Request
   or Data-Probe and the source port of the Map-Reply message is set to
   the well-known UDP port 4342.

For data plane LISP encapsulation, Section 4 says:

  o  RLOCs are always IP addresses assigned to routers; preferably,
      topologically-oriented addresses from provider CIDR blocks.

   o  When a router originates packets it may use as a source address
      either an EID or RLOC.  When acting as a host (e.g. when
      terminating a transport session such as SSH, TELNET, or SNMP), it
      may use an EID that is explicitly assigned for that purpose.  An
      EID that identifies the router as a host MUST NOT be used as an
      RLOC; an EID is only routable within the scope of a site.  A
      typical BGP configuration might demonstrate this "hybrid" EID/RLOC

So the encapsulated packets with the source of an RLOC (LISP sites talking to LISP sites) are expected to pass uRPF checks on the PE (and elsewhere upstream of the ITR).  I'm sure some suggested text would be welcome if you'd like to expand on this further, or maybe something can be added to the security section along the lines of what is in the Interworking draft.

For LISP to non-LISP site communications, the Interworking document (draft-ietf-lisp-interworking-01) contains the following in Section 9:

   When LISP sites send packets to non-LISP sites (these non-LISP sites
   rely on PITRs to enable Interworking), packets will have the Site's
   EID as its source IP address.  These EIDs may not be recognized by
   their Internet Service Provider's Unicast Reverse Path Forwarding
   (uRPF) rules enabled on the Provider Edge Router.  Several options
   are available to the service provider.  For example they could enable
   a less strict version of uRPF, where they only look for the existence
   of the the EID prefix in the routing table.  Another, more secure,
   option is to add a static route for the customer on the PE router,
   but not redistribute this route into the provider's routing table.
   Finally, Proxy-ETRs can enable LISP sites to bypass this uRPF check
   by encapsulating all of their egressing traffic destined to non-LISP
   sites to the Proxy-ETR (thus ensuring the outer IP source address is
   the site's RLOC).

The above paragraph might more directly address your uRPF concerns.

> mechanism(s) to prevent this from happening.

Well, personally I don't think it can, since EIDs are globally unique (unless they are being NAT'd (no different than IPv4/IPv6 addresses), and the mapping between EID and RLOC is publicly visible (see draft-ietf-lisp-lig-01.txt).  

-Darrel