[lisp] #24: Encapsulated control packets on the LISP data port 4341

["lisp issue tracker" <trac at tools.ietf.org>]

#24: Encapsulated control packets on the LISP data port 4341
-------------------------------+--------------------------------------------
Reporter:  darlewis at cisco.com  |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Problem summary:

   LISP implementors and lisp at ietf.org 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.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/24>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues