[lisp] proposed fix issue #22 - processing of Encapsulated Map Requests

[Vince Fuller <[e-mail]>]

Hi Sam-

Here's how the LISP co-authors want to resolve the open issue around the
origination and processing of Encapsulated Map Requests by ITRs,
Map-Resolvers, Map-Servers, and ETRs. During implementation, we actually
ran this before it was raised on the mailing list and believe we have a
simple but effective way to deal with it.

We plan to incorporate new text in new revisions of the affected drafts
(draft-ietf-lisp-05, draft-ietf-lisp-ms-03, draft-lisp-multicast-02).

	Thanks,
	--Vince
	(for the LISP-main and LISP-MS co-authors)

		--------------------

Problem summary:

  LISP implementors and [e-mail] list members have independently found
  a design and implementation issue with the origination and processing of
  Encapsulated Map-Requests. The LISP team proposes changes to both the base
  LISP specification (currently, draft-ietf-lisp-04.txt) and to LISP-MS
  (draft-ietf-lisp-ms-02.txt) to address this. Since LISP Multicast
  (draft-ietf-lisp-multicast-01.txt) also uses problematic encapsulation
  for certain control traffic, it will also need to be modified.
  
Background:

  The current LISP-MS document (draft-ietf-lisp-ms-02) states that an ITR
  sending a Map-Request to a Map-Resolver sets the destination IP address
  of the message to the EID it is requesting and the destination UDP port
  number to 4342 (LISP-CONTROL). The ITR then adds an additional IP+LISP
  header using the Map-Resolver RLOC as the destination IP address and UDP
  destination port 4341 (LISP-DATA). The message is sent to a configured
  Map-Resolver which decapsulates the Map-Request and forwards it on to the
  ALT. If the destination LISP site is using a Map-Server, the Map-Server
  receives the Map-Request on the ALT then re-encapsulates the message with
  an IP+LISP header using the RLOC of the ETR registered for that EID as the
  destination IP address and UDP destination port 4341 (LISP-DATA).

Why the extra encpaulsation from ITR to MR and from MS to ETR?

  When an ITR is using a Map-Resolver, the ITR is not connected to the ALT
  and therefore has no way to route control messages destined to an EID. For
  this reason, the ITR uses the RLOC of a configured Map-Resolver as the
  destination IP address for Map-Requests; an RLOC, by definition, is
  routable on the non-LISP part of the Internet. To be forwarded on to
  the ALT, though, the target EID is also needed as a destination IP
  address. Adding an extra encpasulation header allows two-stage routing
  to the destination addresses used in those different contexts.

  Similarly, since an ETR using a Map-Server is not connected to the ALT,
  traffic between between Map-Server and ETR must use RLOC-based native
  forwarding. An ETR thus sends its Map-Register messages using its RLOC as
  the IP source address and the Map-Server RLOC as the IP destination.
  Likewise, a Map-Server forwards Map-Requests to an ETR using its RLOC as
  the IP source address and the ETR RLOC as the IP destination; to do this,
  it must encapsulate the original Map-Request since the original destination
  IP address is an EID that is only routable on the ALT.

Problem details:

  As described above, an Encapsulated Map Request currently uses destination
  UDP port 4341 (LISP-DATA). This creates two potential problems:

  1) A packet received by an ETR on port UDP 4341 cannot be immediately
     determined to be control or data. This means that an ETR must perform
     significant processing on such a packet before determining whether it
     needs to either take some control action or forward the packet to a
     destination host. This could make it difficult to implement ETR
     functionality on a router that uses specialized forwarding hardware.

  2) It is currently possible for an encapsulated user UDP datagram received
     by an ETR with outer header UDP port 4341 to be misinterpreted as an
     Encapsulated Map Request. This is because an end system application can
     use UDP port 4342 as a source port for traffic. Return traffic to an
     such an application would be received by an ETR with outer header
     destination port 4341 (LISP-DATA) and inner header destination UDP port
     4342; this could be consumed by an ETR and not forwarded correctly. The
     assignment by the IANA of well-known LISP "service" port numbers will
     prevent this problem in the future but there may be difficulties with
     early trials and deployment prior to such an assignment.

Solution:

  1) Modify the base LISP specification (draft-ietf-lisp-05) to define a new
     LISP control message type called Encapsulated Control Message.

  2) Modify the LISP-MS document (draft-ietf-lisp-ms-03) to specify that
     Encapsulated Map Requests use the new message type and that they are
     sent to UDP port 4342 (LISP-CONTROL) instead of 4341 (LISP-DATA).

  3) Modify the LISP Multicast document (draft-ietf-lisp-multicast-02.txt)
     to similarly replace all use of UDP port 4341 with port 4342 for
     encapsulated unicast PIM Join/Prune messages.

  These changes greatly simplify processing of LISP packets by an ETR: all
  traffic received on UDP port 4341 is decapsulated and forwarded to an end
  system while all traffic received on port 4342 is processed by the ETR
  itself. Furthermore, these changes eliminate any user vs. control message
  ambiguity for traffic received by an ETR on port 4341.