Subject: [lisp] #22: An ETR MUST consume UDP port 4342 packets not addressed to it

From: "lisp issue tracker" <[email-masked]>
Date: Tue, 08 Sep 2009 02:31:50 -0000

#22: An ETR MUST consume UDP port 4342 packets not addressed to it
----------------------------------+-----------------------------------------
Reporter:  [email-masked]  |       Owner:     
    Type:  technical              |      Status:  new
Priority:  major                  |   Component:  alt
Severity:  -                      |    Keywords:     
----------------------------------+-----------------------------------------
 Two aspects of the MS protocol require that an ETR consume packets not
 addressed to it.  (There are also cases where an ETR or LISP+alt
 router consumes alt packets not addressed to it; those cases seem fine
 to me.  If desired I can explain my reasoning.)

  # an ITR sends an encapsulated map request to a map resolver
  # an map server sends an encapsulated request to an ETR

 An encapsulated map request typically has the source RLOC of the ITR
 for both the inner and outer header, and has the EID of the
 destination of the map request for the inner IP header.  The outer
 destination UDP port is 4341 (the LISP data port).  The inner
 destination UDP port is 4342.

 The problem here is that the box doing LISP decapsulation needs to do
 special processing on packets not destined for it.  This complicates
 the data plane implementation.  Also, this violates the end-to-end
 principle and the IP service model.  There are very few situations
 when a router is expected to consume a packet not destined for it;
 none of them apply here as far as I can tell.

 I think the architecture is bad enough that this should change.  But the
 practical effects are also problematic:
  * The data plane stack on the router needs to handle IP options, hop-by-
 hop options, and destination options the same way as the UDP stack in the
 control plane in order to avoid  inconsistent behavior.

  * Whether you reach port 4342 on the end-system named by an EID  or
 whether your packet is consumed by an intermediate router depends on where
 you are in the topology.

 Instead, I propose that:

 An ITR should send a UDP packet with source IP address of one of its
 RLOCs, destination IP address of the map resolver's RLOC, and
 destination UDP port 4342.  The map resolver should receive this
 packet and generate a similar map request over the alt with source IP
 address of the ITR's RLOC, destination address of the EID within the
 map request to UDP port 4342.  We need to decide how to handle the
 situation where the source RLOC and destination EID are in different
 address families.  I don't think this case is fully specified with the
 existing mechanism, and I can think of some ways to make this work
 without encapsulation but need to think more about it.

 A map server should receive a packet on UDP port 4342 over an alt
 interface.  (Receive is kind of a stretch here as huge chunks of the
 EID space may be "routed" to the map server.)  If the EID is in a
 prefix registered with this map server, then the map server should
 generate a packet to UDP port 4342 on the RLOC registered with the
 prefix, source IP address copied from the packet received or the ALT
 and destination address of the RLOC of the prefix.

 One way to handle the cross-address-family complexity would be to have
 a way to specify the reply source locator in a mapping request.
 Really, unless you can include a locator of each address family you
 support in a mapping request, you cannot be sure that the other side
 will be able to reply to you.

 An alternative solution that would address my architectural concerns
 would be to send encapsulated map requests to some port other than
 4341--perhaps even 4342.  I don't prefer that solution and would like
 to explore all the options that avoid map request encapsulation before
 we go down that route, but it is an option of last resort to make it
 possible to unambiguously implement an ETR.

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 08 Sep 2009 10:31:32 -0400

In trying to understand this question, and its implications, I seem to 
have totally confused myself.  (Sorry Dino.  I think you explained this 
to me once before, and convinced me.  But I can not reconstruct it now.)

The underlying goal is to get a LISP control message, in this case a 
mapping request, from the source to the entity that can provide a useful 
answer.
The ITR wants to send the request to its Map Server.
The Map Server send the request over the ALT to the relevant Map Responder.
The Map Responder sends the request to a relevant ETR.

The Control request is an IP packet, with a UDP header, addressed to UDP 
port 4342.  The body of the request includes the information as to the 
EID whose mapping is being sought, and the RLOC of the ITR who is making 
the request.

By assumption, that RLOC is usable by the end ETR to send the response 
back to the ITR.

So why do we need two UDP headers (and two IP headers.)
The ITR can send the packet to the MS>  So it should only need on IP 
header, source=ITR RLoc, Dest=MS RLoc.  And one UDP header (for control 
message.)

Similarly, the MR needs to send the message to the ETR.  But the MR know 
the ETR Rloc.  So a single IP header, source=MS RLoc, dest=ETR Rloc, and 
a single UDP header for the control message, would seem sufficient.

This would mean that nodes are only processing messages addressed to 
themselves.  This would also seem to be completely separate from the 
question of what format messages are sent over the GRE tunnel inside the 
ALT.

Assuming I am missing something basic, I suspect we need some more text 
somewhere.  I paged back and forth through the LISP spec, the LISP-ALT 
spec, and the LISP-MS spec.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 8 Sep 2009 08:13:05 -0700

Joel, see the enclosed slide. Follow the steps (1) through (5). That  
is what is implemented now and reflects what is in the current set of  
specs (-04 doesn't change this procedure). This should help clarify  
things.

> In trying to understand this question, and its implications, I seem  
> to have totally confused myself.  (Sorry Dino.  I think you  
> explained this to me once before, and convinced me.  But I can not  
> reconstruct it now.)
>
> mapping request, from the source to the entity that can provide a  
> useful answer.

Right.

> The ITR wants to send the request to its Map Server.

The ITR sends it to the mapping data system. The ITR is configured  
with the locator address of the Map-Resolver. Once the encapsulated  
Map-Request gets to the Map-Resolver, the mapping database system gets  
the Map-Request to the authoritative ETR.

In ALT, that means the Map-Request gets to the Map-Server the ETR  
registered to. Then the Map-Server encapsulates the Map-Request to get  
it to the ETR.

Remember, the fundamental premise of LISP is "outer headers have  
locators in them" and "inner headers have EIDs in them". This is true  
with control packets, but control packets can have either locators or  
EIDs in the inner header.

> The Map Responder sends the request to a relevant ETR.

No, the text above should clarify this.

> The Control request is an IP packet, with a UDP header, addressed to  
> UDP port 4342.  The body of the request includes the information as  
> to the EID whose mapping is being sought, and the RLOC of the ITR  
> who is making the request.

Right. But that packet can't leave the ITR or else the destination  
address (the EID being sought) cannot be routed (assuming that EID- 
prefixes are not in the underlying routing). So the ITR must  
encapsulate the Map-Request so there can be locators in the other  
header.

Also, if the Map-Request is an IPv6 Map-Request and you only have an  
IPv4 path to the mapping database system, then the inner header would  
have a source address of an IPv6 locator, a destination address of an  
IPv6 EID and the outer header would have source and destination IPv4  
locators (see spec how Map-Reply gets returned in the mixed-AF case).

> By assumption, that RLOC is usable by the end ETR to send the  
> response back to the ITR.

Yes, the Map-Reply is sent directly from ETR to ETR with locators in  
the headers. There is no encapsulated Map-Reply.

> So why do we need two UDP headers (and two IP headers.)

Should be clear now? See slide?

> header, source=ITR RLoc, Dest=MS RLoc.  And one UDP header (for  
> control message.)
>
> Similarly, the MR needs to send the message to the ETR.  But the MR  
> know the ETR Rloc.  So a single IP header, source=MS RLoc, dest=ETR  
> Rloc, and a single UDP header for the control message, would seem  
> sufficient.
>
> question of what format messages are sent over the GRE tunnel inside  
> the ALT.

There is one case where an ETR will process a control packet not  
addressed to it. We found this to be an issue 2 weeks ago while doing  
our implementation.

We will document this on the mailing list once -04 gets out. It should  
address the concerns that was brought up in the tracker #22 item.

Vince will send email once we get -04 out.

> Assuming I am missing something basic, I suspect we need some more  
> text somewhere.  I paged back and forth through the LISP spec, the  
> LISP-ALT spec, and the LISP-MS spec.

Hmm. Maybe it's because you have the map-server and map-resolver  
functions not square? But we will try to clarify the spec.

Dino

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 08 Sep 2009 12:57:47 -0400

Yes, I got the map resolver and map server backwards.  But that does not 
change the question.

Fundamentally, for LISP control packets, I do not see why we need an 
inner IP header.  The Control packet format itself has enough 
information about the source and target of the message.

You suggest that there would be a problem if the RLoc is IPv6, but the 
connectivity to the Map Resolver is IPv4.
Presumably, given that the ITR has IPv4 connectivity, there is also an 
IPv4 RLoc.
Whether the EID is v4 or v6 is irrelevant, as that is in the control packet.
Even strange mixings of v4 Mapping and v6 RLocs seem possible even 
without the outer header.  The RLoc that the sending ITR uses in the 
control part of the message does not ahve to match the RLoc it uses as 
the UDP source address.

You seem to be assuming that in the Map Request the target EID has to go 
in the inner destination IP address field.  Given that the address is in 
the control message, I do not see why that is the case.
It may be the case that within the ALT we want to send the packets that 
way.  But we are not discussing the encapsulation between ALT elements. 
  We are discussing the ITR->MR and MS->ETR encapsulation.  It seems 
that those boxes at the edge of the ALT can deal with building headers 
that are suitable for traversing the ALT.

Just to complete the story, for the last leg from the MS to the ETR, I 
do not see why the RLoc of the ITR needs to appear in the IP (inner or 
outer) header.  It appears in the control message itself.  The ETR can 
get the information from there for composing the direct response.

Still confused,
Joel

Dino Farinacci wrote:
> Joel, see the enclosed slide. Follow the steps (1) through (5). That is 
> what is implemented now and reflects what is in the current set of specs 
> (-04 doesn't change this procedure). This should help clarify things.
> 
>> have totally confused myself.  (Sorry Dino.  I think you explained 
>> this to me once before, and convinced me.  But I can not reconstruct 
>> it now.)
>>
> The ITR sends it to the mapping data system. The ITR is configured with 
> the locator address of the Map-Resolver. Once the encapsulated 
>> UDP port 4342.  The body of the request includes the information as to 
>> the EID whose mapping is being sought, and the RLOC of the ITR who is 
>> making the request.
> 
> address (the EID being sought) cannot be routed (assuming that 
> EID-prefixes are not in the underlying routing). So the ITR must 
> encapsulate the Map-Request so there can be locators in the other header.
> 
> Yes, the Map-Reply is sent directly from ETR to ETR with locators in the 
> headers. There is no encapsulated Map-Reply.
>

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 8 Sep 2009 15:44:15 -0400

On Sep 8, 2009, at 12:57 PM, Joel M. Halpern wrote:

> Yes, I got the map resolver and map server backwards.  But that does  
> not change the question.
>
> You suggest that there would be a problem if the RLoc is IPv6, but  
> the connectivity to the Map Resolver is IPv4.
> Presumably, given that the ITR has IPv4 connectivity, there is also  
> an IPv4 RLoc.
> control part of the message does not ahve to match the RLoc it uses  
> as the UDP source address.
>
> You seem to be assuming that in the Map Request the target EID has  
> to go in the inner destination IP address field.  Given that the  
> address is in the control message, I do not see why that is the case.
> It may be the case that within the ALT we want to send the packets  
> that way.  But we are not discussing the encapsulation between ALT  
> elements.  We are discussing the ITR->MR and MS->ETR encapsulation.   
> It seems that those boxes at the edge of the ALT can deal with  
> building headers that are suitable for traversing the ALT.
>
> Just to complete the story, for the last leg from the MS to the ETR,  
> I do not see why the RLoc of the ITR needs to appear in the IP  
> (inner or outer) header.  It appears in the control message itself.   
> The ETR can get the information from there for composing the direct  
> response.

I'm suffering from the same confusion as Joel...

I don't see any value to encapsulating the ITR-to-MR and MS-to-ETR  
control plane packets, and I see considerable cost to doing so because  
it adds complexity and processing overhead to what should be a simple  
forwarding function in the LISP data plane.  I understand that the ALT  
is special, but at the edges let's send the control packets directly  
to their intended recipients on the LISP control port, instead of  
encapsulating them.

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 8 Sep 2009 14:46:04 -0700

>> Yes, I got the map resolver and map server backwards.  But that  
>> does not change the question.
>>
>> Fundamentally, for LISP control packets, I do not see why we need  
>> an inner IP header.  The Control packet format itself has enough  
>> without the outer header.  The RLoc that the sending ITR uses in  
>> the control part of the message does not ahve to match the RLoc it  
>> uses as the UDP source address.
>>
>> elements.  We are discussing the ITR->MR and MS->ETR  
>> encapsulation.  It seems that those boxes at the edge of the ALT  
>> can deal with building headers that are suitable for traversing the  
>> ALT.
>>
>> Just to complete the story, for the last leg from the MS to the  
>> ETR, I do not see why the RLoc of the ITR needs to appear in the IP  
>> (inner or outer) header.  It appears in the control message  
>> itself.  The ETR can get the information from there for composing  
>> the direct response.
>
>
> control plane packets, and I see considerable cost to doing so  
> because it adds complexity and processing overhead to what should be a

This is an originated control packet, so the control plane puts the  
encapsulated header on. So it is very simple. The data-plane need not  
be involved.

If you choose any other method you can't support all the combinations  
we tend to support. That is mixed address-families, xTRs attached to  
the ALT, LISP-naive ALT routers, and there are more.

> simple forwarding function in the LISP data plane.  I understand  
> that the ALT is special, but at the edges let's send the control  
> packets directly to their intended recipients on the LISP control  
> port, instead of encapsulating them.

You can't do that because the packet will be dropped by the PE router  
because there is no route in the underlying routing for the EID.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 08 Sep 2009 18:02:01 -0400

As far as I can tell, all of the different address combinations can be 
handled without the double-header on the leaf->Map Service connection. 
The necessary data is in the Map Request.  And this does not have to 
match the enclosing IP header as to IP version.   (It does have to match 
the kind of EID the ALT is prepared to handle, but that is true anyway.)

What can not be handled is transparently removing the ITR - Map Service 
connection.  But I do not understand the issue.  Given how simple the 
Map Responder (and Map Server?) logic are, it would seem natural to 
include that in any LISP-ALT leaf device (probably in any LISP-ALT 
device, for simplicity.

Given that ALT devices talk to each other over GRE, if we want the ITR 
to send the query into the ALT system, it presumably has to do so over a 
GRE tunnel.  So the ITR logic is now different anyway.  So it can change 
the encapsulation.  (If the ITR does not have to use GRE, then the 
LISP-ALT device is supporting two formats, and it might as well support 
the format that simplifies the client.)

I suspect one of the keys to the difference is that I do not expect that 
the device which receives requests from clients can simply forward those 
based on the EID in the IP header.  I expect validation is needed, cache 
checking, etc.  And given taht we are dealing with LISP, the need for 
such a device to add an extra header seems irrrelevant to me.

I am also confused because it seems that your unstated goal is for the 
Map Responder (and Map Server) protocol to be the same as the protocol 
that you are trying to isolate the ITR/ETR from.  I thought the goal was 
to keep the ITR / ETR simpler.
Admittedly, simplicity is in the eye of the beholder.  And there is 
always the question of where the necessary complexity belongs.

Yours,
Joel

Dino Farinacci wrote:
>>> You seem to be assuming that in the Map Request the target EID has to 
>>> go in the inner destination IP address field.  Given that the address 
>>> is in the control message, I do not see why that is the case.
>>> I do not see why the RLoc of the ITR needs to appear in the IP (inner 
>>> or outer) header.  It appears in the control message itself.  The ETR 
>>> can get the information from there for composing the direct response.
>>
>>
>> it adds complexity and processing overhead to what should be a
> 
> encapsulated header on. So it is very simple. The data-plane need not be 
> involved.
> 
> If you choose any other method you can't support all the combinations we 
> tend to support. That is mixed address-families, xTRs attached to the 
> ALT, LISP-naive ALT routers, and there are more.
> 
>> simple forwarding function in the LISP data plane.  I understand that 
>> the ALT is special, but at the edges let's send the control packets 
>> directly to their intended recipients on the LISP control port, 
>> instead of encapsulating them.
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 8 Sep 2009 15:16:26 -0700

> As far as I can tell, all of the different address combinations can  
> be handled without the double-header on the leaf->Map Service  
> connection. The necessary data is in the Map Request.  And this does  
> not have to match the enclosing IP header as to IP version.   (It  
> does have to match the kind of EID the ALT is prepared to handle,  
> but that is true anyway.)

It is also about debuggability. You want to know who builds a packet,  
and who is forwarding or encapsulating. The level of indirection  
allows the map-resolver to reencapsulate perhaps and provides  
opportunities to do caching in other parts of the infrastructure. We  
don't know right now if that is a good idea but the level of  
indirection helps us.

We don't want the map-resolver to look into the contents of the ITR  
built packet. It could be encrypted in the future. The Map-Resolvers  
and Map-Servers act as a service interface for sites. So they are  
really simple by decap'ing and forwarding packets on the ALT.

The ITR and ETR functionality is really simple too. They just build  
Map-Requests for the address-family the EID is being sought for and if  
there is a bottom layer that decides if the packet is sent directly on  
an ALT, or a DHT, or to a map-resolver, this is done independent of  
the LISP core protocol functionality.

Encapsulating at the ITR to get a Map-Request to a Map-Resolver is  
trivial. Just slap a header on the packet and put the configured map- 
resolver as the destination address in the outer header. And pick a  
local RLOC for the source address. That is all there is to it.

> What can not be handled is transparently removing the ITR - Map  
> Service connection.  But I do not

That is exactly what the MR/MS architecture is doing.

> understand the issue.  Given how simple the Map Responder (and Map  
> Server?) logic are, it would seem natural to include that in any  
> LISP-ALT leaf device (probably in any LISP-ALT device, for simplicity.
>
> Given that ALT devices talk to each other over GRE, if we want the  
> ITR to send the query into the ALT

That is the way it is spec'ed out but it doesn't have to be GRE. It  
can be dark fiber, it can be 802.1Q, it can be L2TP, pseudo-wires. But  
what is important is that the object being sought for is in the  
destination field of the IP header. That allows ALT to be taken out  
and DHT put in and the key is still in the destination address of the  
IP header.

You don't want these devices to have to parse the LISP payload. In  
fact, if you use data-probes on the mapping database, there is no  
where else to put the EID but in the destination address field.

And there are some of the mind, that dropping or queuing packets is  
not good and sending data-probes to solicit Map-Replies is a way to go.

> system, it presumably has to do so over a GRE tunnel.  So the ITR  
> logic is now different anyway.  So it can change the encapsulation.   
> (If the ITR does not have to use GRE, then the LISP-ALT device is  
> supporting two formats, and it might as well support the format that  
> simplifies the client.)

No, not really two formats. The inner Map-Request uses the same code  
to build the packet. You just do something more afterwards. I can show  
you the code Joel.  ;-)  It's not different, it's in addition to. It  
makes a big difference.

> I suspect one of the keys to the difference is that I do not expect  
> that the device which receives requests from clients can simply  
> forward those based on the EID in the IP header.  I expect  
> validation is needed, cache checking, etc.  And given taht we are  
> dealing with LISP, the need for such a device to add an extra header  
> seems irrrelevant to me.

Well how much validation does a DNS server to when a query comes in.  
Even if you wanted to force policy here, just think of the OpEx hit to  
manage this.

> I am also confused because it seems that your unstated goal is for  
> the Map Responder (and Map Server) protocol to be the same as the  
> protocol that you are trying to isolate the ITR/ETR from.  I thought  
> the goal was to keep the ITR / ETR simpler.

It is simpler for the user. There is no BGP configuration on the xTRs.  
Simpler for the protocol developer is secondary to the user. But I  
believe it's not bad for the developer.

> always the question of where the necessary complexity belongs.

Simplicity must be in the eye of the poor network administrator that  
has to configure, manage, and monitor the routing system.

Dino

>>>> You suggest that there would be a problem if the RLoc is IPv6,  
>>>> but the connectivity to the Map Resolver is IPv4.
>>>> Presumably, given that the ITR has IPv4 connectivity, there is  
>>>> also an IPv4 RLoc.
>>>> Even strange mixings of v4 Mapping and v6 RLocs seem possible  
>>>> even without the outer header.  The RLoc that the sending ITR  
>>>> uses in the control part of the message does not ahve to match  
>>>> the RLoc it uses as the UDP source address.
>>>>
>>>> You seem to be assuming that in the Map Request the target EID  
>>>> has to go in the inner destination IP address field.  Given that  
>>>> the address is in the control message, I do not see why that is  
>>>> the case.
>>>> It may be the case that within the ALT we want to send the  
>>>> packets that way.  But we are not discussing the encapsulation  
>>>> between ALT elements.  We are discussing the ITR->MR and MS->ETR  
>>>> can deal with building headers that are suitable for traversing  
>>>> the ALT.
>>>>
>>>> ETR, I do not see why the RLoc of the ITR needs to appear in the  
>>>> IP (inner or outer) header.  It appears in the control message  
>> encapsulated header on. So it is very simple. The data-plane need  
>> not be involved.
>> If you choose any other method you can't support all the  
>> combinations we tend to support. That is mixed address-families,  
>> xTRs attached to the ALT, LISP-naive ALT routers, and there are more.
>> You can't do that because the packet will be dropped by the PE  
>> router because there is no route in the underlying routing for the  
>> EID.
>> Dino