Encapsulated control packets on the LISP data port 4341

[darlewis@…]

Problem summary:

LISP implementors and lisp@… 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.

[hartmans-ietf@…]

The working group reached rough consensus that the solution proposed improves the situation and was a good step forward while discussing #22 in detail. So, the text was adopted.