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

From: [email-masked] (Noel Chiappa)
Date: Tue, 22 Sep 2009 11:27:10 -0400 (EDT)

> From: Sam Hartman <[email-masked]>

Went back to re-read this to make sure I'd understood your issue properly,
and I see I was confused (this is getting somewhat repetitious... :-)

    > Under your solution, I'm still required to consume UDP packets not
    > destined to myself. ... I'm an ETR. I receive a control packet ...
    > Inside that packet is another IP header, another UDP header, and the
    > actual map request. That inner IP header is not addressed to me.

Let me make sure I understand this.

This ETR actually _is_ the machine that Map-Request should properly be
forwarded to, _but_ because the orignating ITR didn't know the ETR's RLOC
(all it knew was what EID it wanted looked up), that header can't contain
the ETR's RLOC. (It happens to contain the destination EID, which is a
hack to help ALT, more below.)

    > So, I still cannot pass this packet to my local IP and UDP stack.

There is a hack around this, (just bash the inner destination IP address
to be your own, adjust the IP and UDP checksums (it will be the same value
to add to both), and then pass the packet to your local stack), but I'm
not sure that's the right answer anyway....

    > In conclusion, I don't think this proposal fully addresses my
    > problem.

But is doing a whole new Map-Request format the right answer either,
_particlarly_ when that oddball Map-Request is only needed to work with a
particular mapping system (ALT), which might well be replaced down the
road?

(At this point I went back and re-read Vince's original message.)

To me, part of the charm of the whole Map-Resolver/etc stuff was that it
insulated the xTRs from the details of the mapping system, meaning we
could replace it more easily. But these 'tendrils' are starting to creep
in, where we are tuning the underlying basic map-resolution mechanism to
the details of the ALT.

	Noel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Sep 2009 11:44:24 -0400

But this does not call for a whole new Map-Request format.  The existing 
Map-Request format has all the information that is needed for 
processing, passing on, and responding to, the request.  The inner UDP 
header repeats information from the Map-Request itself.

I suspect that at this point we need to wait and let the US west coast 
have a chance to digest this exchange, so that they can speak for 
themselves.

Yours,
Joel

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

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 22 Sep 2009 11:47:03 -0400

> hack to help ALT, more below.)

True, except you haven't explained why we need this header at all...

What if the ITR sent a simple question to the Map Resolver of the form  
"What RLOC(s) should I use to reach this EID (or EID prefix)?".  This  
could be sent from one of the ITRs RLOCs to the Map Resolver, and we  
don't need to use any non-routable EIDs in the IP header(s) at all.

I _understand_ that the ALT mapping system relies on using the EID as  
a destination address _inside the ALT_ in order to reach the right  
mapping server to resolve the request.  But, that ALT-specific detail  
should remain hidden inside the ALT, IMO.

> not sure that's the right answer anyway....

The fact that that just bashing the address could work points out why  
this type of encapsulation isn't needed at all.  The EID for the  
request is already in the Map Request itself, so there isn't any need  
to include it in an encapsulated header.

> particular mapping system (ALT), which might well be replaced down the

Who said we'd need a whole new Map-Request format?  We're asking for a  
simpler encapsulation, not a whole new format.
> in, where we are tuning the underlying basic map-resolution  

What Vince has proposed does the exact _opposite_ of isolating the  
xTRs from the mapping system, as they are required to build mapping- 
system-specific requests (using EIDs as destination addresses) and  
then encapsulate them to get them to the mapping system.  A system  
where we ask simple questions like "What RLOC(s) should I (as an ITR)  
use to reach this EID (or EID prefix)?" and get simple answers like  
"Use this/these RLOC(s) to reach this EID Prefix" over a simple  
(unencapsulated) transport would actually _hide_ the details of the  
mapping system from the xTRs.

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Sep 2009 09:13:34 -0700

> But this does not call for a whole new Map-Request format.  The  
> existing Map-Request format has all the information that is needed  
> for processing, passing on, and responding to, the request.  The  
> inner UDP header repeats information from the Map-Request itself.

The only item repeated is the UDP header. So what?

> I suspect that at this point we need to wait and let the US west  
> coast have a chance to digest this exchange, so that they can speak  
> for themselves.

Indigestion.   ;-)

Dino

---

From: John Zwiebel <[email-masked]>
Date: Tue, 22 Sep 2009 18:12:40 -1000

> True, except you haven't explained why we need this header at all...

We don't "need" it.  There are many ways it could be done.
This was the choice that was made based on experience with the
systems LISP was being built on.

It is an EXPERIMENT.

> What if the ITR sent a simple question to the Map Resolver of the  
> form "What RLOC(s) should I use to reach this EID (or EID prefix)?".

Because this requires an extra step that we don't want the ITR to  
have to deal with.
The ITR wants to send map-requests one place, that's the map resolver.

If your thought is that the map-resolver provides the RLOC of the  
ETR, the problem
is that it (the MR) isn't "authoritative".  The only one who really  
knows what EIDs it serves is
the ETR itself.  The current desire is to always get the latest  
information from the most
authoritative source.  If you have the intermediate step you have  
delay problems or
attack problems.

>   But, that ALT-specific detail should remain hidden inside the  
> ALT, IMO.

IMHO, (note I'm trying to be humble) it is.

The fact that the ITR sends the control message to the MR first is just
a simple way of injecting the map-request into the ALT.

We used to have the ITR actually join the ALT, but then it had to run  
BGP over
the ALT.  It worked just fine, but the architects thought it could  
result in a larger
BGP topology than they wanted.  I agree.

Changing the format of the message sent from the ITR to whatever mapping
distribution system exists should be considered.  But I believe the  
current
EMR format could be used no matter what was substituted in.

This is an experiment.

>
> The fact that that just bashing the address could work points out  
> why this type of encapsulation isn't needed at all.  The EID for  
> the request is already in the Map Request itself, so there isn't  
> any need to include it in an encapsulated header.
>

You -may- be right that it isn't needed.  It is just easier to do it  
this way.
Its already done and it works.  The decision to back up and start over
isn't what I would think would fit into an "experiment" unless there is
some overwhelming evidence that what already works isn't going to
continue working.

> then encapsulate them to get them to the mapping system.

This is extremely simple.  Much, much easier than having to be a  
member of the ALT.
In any case, its hard for me to imagine how it could be easier for  
the ITR to build
the map-request.  Seems to me that exactly the same information will  
have to be sent
even if it is in a different format.

> A system where we ask simple questions like "What RLOC(s) should I  
> (as an ITR) use to reach this EID (or EID prefix)?" and get simple  
> answers like "Use this/these RLOC(s) to reach this EID Prefix" over  
> a simple (unencapsulated) transport would actually _hide_ the  
> details of the mapping system from the xTRs.

At the cost of throwing away tons of stuff that has already been  
implemented and
proven to work, for absolutely no proven gain in functionality other  
than it appears
to be cleaner.

In your system the ITR sends a message to the map-resolver.

In the current system the ITR sends a message to the map-resolver.

They look pretty much identical to me.  The only difference is the
format of the bits.

Joel brought up the question of debugging.

As one who has had to look at tons and tons of these messages being  
forwarded,
it is a whole lot easier to monitor the change of the external header  
keeping the
inner packet exactly the same than it is to figure out if the control  
packet that
came in generated the right control packet on the way out.

In a different email margaret said:

> Your current perception of the MR and MS as BGP routers is  
> understandable, given the nature of the ALT.  However, that isn't  
> guaranteed to be a constant for LISP.

True, but if I were to bet, I'd give 10 to 1 odds on the ALT.  I've  
lost bets.
I sold my Apple several months ago.  (Oh well)

And if something else were to be substituted in, I see no need to change
the format of the messages sent from the ITR.  You might change them,  
but
you don't actually need to change them.

In this thread, we're talking about whether or not it is easy for a  
given platform/OS to
process the messages.  While this is important in a final RFC, LISP  
is an experiment.
It may not work at all.

Or perhaps we're past that point?  Is there actually a consensus that  
LISP will be
deployed and will actually solve the problem?  If so, then I back off  
completely.

I guess the only way to know is to call for such a consensus.  Any  
one want to
say yes?  (I'm not willing to go that far yet.)

> So, it doesn't make architectural sense for an ITR to build an  
> encapsulated ALT mapping packet and send it to the MR.

It does to me.  Its easy to implement.  It works.  Its easy to debug.
It makes as much sense as any other way I've seen proposed on this  
list so far.

> I also don't think it is realistic that the MR/MS will remain as  
> simple as you describe, nor do I believe that it is possible (or  
> even desirable) for the MR or the MS  to have no LISP-specific code.

This is an argument without any basis.  There are no alternate  
proposals that don't have
LISP-specific code.  I find it very hard to understand how a LISP map- 
request could be
processed by any system that didn't have "LISP-specific code".

Rather the ALT does -NOT- require LISP specific code.  Seems like  
this meets your
requirements.

> ITRs register with Map Servers,

ETRs register with map servers.

> There are also likely to be a number of anti-spoofing requirements  
> for the mapping system that go well beyond the need to read the EID  
> from the request.

This is suppose to be an experiment.  The purpose of the experiment  
is to prove the
viability of the LISP concept.  If there are gross security problems  
in the LISP concept,
to the extent that it becomes non-deployable, then you'd have an  
excellent point.  But
unless you can describe a spoof that -I- will easily understand, the  
claim for 'anti-spoofing'
requirements is well beyond what I would consider to be an Experiment.

Joel said:

> If MR and MS nodes are pure relay, then in order to change the  
> format of a Map Query, as sent by an ITR, every ETR in the world  
> would have to have the upgraded software.
> In contrast, MS could accept an alternative form, and transform it  
> to whatever the ALT handles.

Actually the MR does the acceptance to send the request on to the ALT.

> And MRs (which have registrations from ETRs) could, at least in  
> theory, transform the ALT format into whatever the ETR wants.

ETRs register to the map-server.  I totally agree that the MS can  
change the format to whatever.
Therefore, what we have works.  I don't see any reason to change it now.

6 of one 1/2 dozen of the other.  ie whether the MR/MS just relays  
the request or actually
formulates the request based on some other message from the ITR to  
the ETR (processed
by whatever intervening systems you want to use) is something that  
can be determined later.

Now we are suppose to be experimenting to determine whether or not  
the overall LISP
concept works at all.  I have a real problem seeing how much of what  
is discussed on
this list advances that core concept.

> In practice, I think that changing the map request or map response  
> format is going to be extremely difficult under either model.  But  
> if I had to pick one that I thought might be upgradeable, it would  
> be an approach with MR and MS as active components rather than  
> merely relays.

IMHO there is no difference.  In either case the software on the MR/ 
MS will have to be changed.
The message sent from the ITR to the MR or from the MS to the ETR  
would be massaged to
match whatever was expected or desired.  In either case, you probably  
end up with a 'flag-day'
to deploy the new method.  Unless you complicate the protocol even  
more to process both.

This is suppose to be an experiment.  To me, that means concentrating  
on getting
something to actually work rather than worrying about the details of  
how it works.

There is a BGPv4 for some reason.  I'm sure you know better than I  
what that reason is.

DVMRP can't be found any where any longer, yet without it  where  
would multicast be?

OSPF has gone through several iterations.

IMHO the purpose of this group is not to get it perfect the first  
time, but to get something
out there to see if it works at all.   It is an Experiment.

Had we done that with PIM, I guarantee you it would look a lot  
different than it does now.
And interdomain multicast would be a reality rather than some dream.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 24 Sep 2009 10:58:45 -0400

Hi John,

> systems LISP was being built on.

I think that we may be having some sort of misunderstanding regarding  
what it means for the LISP WG to publish the LISP specifications as  
Experimental RFCs.  Here is my thinking...

There are three ways to get an experimental RFC published:

(1) Independent submission to the RFC Editor.  In this case, the  
document would be published as an experimental RFC with limited review  
by the RFC editor for technical and editorial quality.  This would be  
a non-IETF RFC, and would include an IESG note to that effect.  So, if  
all they wanted to do was get their current specification published as  
an experimental RFC, so that there would be a stable basis for  
implementation, this would have been a good choice.

(2) AD-Sponsored individual submission.  To take this path, the  
authors would have needed to find an AD who was willing to sponsor the  
document for publication as an Experimental RFC.  It would have gone  
through AD Review, a 4 week IETF LC (including directorate reviews)  
and IESG review.  When the issues found in those reviews were  
resolved, it could be published as an IETF Experimental RFC.

(3) Form a WG to Refine/Publish the Document.  This is the path that  
was chosen by the authors.  In this case, the document becomes a WG  
document, and will be refined in the WG (based on WG consensus to  
change it) until the WG has consensus to publish it.  At that point,  
it will go through a 2 week WG LC.  It will then be submitted to the  
IESG and go through AD Review.  Because this will be an Experimental  
RFC from a working group, a 2-week IETF LC is optional.  Then it will  
go to IESG (and directorate) review and be published.  The WG path is  
expected to be the longest of the three paths, because of the need to  
produce a document that represents the full consensus of the WG, not  
just of the authors.

Given that the LISP authors chose the WG route, it was my  
understanding that they _wanted_ the LISP RFCs to become WG documents  
and to be actively developed by the WG.  Why else would they have  
chosen this path?

WGs are run in accordance with their charter.  Our charter says (with  
text excerpted to save space):

 > All proposals
 > (including LISP) have potentially harmful side-effects to Internet
 > traffic carried by the involved routers, have parts where deployment
 > incentives may be lacking, and are NOT RECOMMENDED for deployment  
beyond
 > experimental situations at this stage. Many of the proposals have
 > components (such as the identifier to locator mapping system) where  
it
 > is not yet known what kind of design alternative is the best one  
among
 > many.
 >
 > However, despite these issues it would be valuable to write concrete
 > protocol specifications and develop implementations that can be  
used to
 > understand the characteristics of these designs. The LISP WG is
 > chartered to work on ... LISP ... with the
 > given drafts as a starting point. The working group will encourage  
and
 > support interoperable LISP implementations as well as defining
 > requirements for alternate mapping systems. The Working Group will  
also
 > develop security profiles for the ALT and/or other mapping systems.
 >
 > It is expected that the results of specifying, implementing, and  
testing
 > LISP will be fed to the general efforts at the IETF and IRTF (e.g.,  
the
 > Routing Research Group) that attempts to understand which type of a
 > solution is optimal. The LISP WG is NOT chartered to develop the  
final
 > or standard solution for solving the routing scalability problem. Its
 > specifications are Experimental and labeled with accurate disclaimers
 > about their limitations and not fully understood implications for
 > Internet traffic.

This says a few three things to me...

(1) We need to add disclaimers to our documents, as described in the  
charter (please open a separate issue for this).

(2) The WG is expected to encourage and support interoperable  
implementations.  To my way of thinking, part of encouraging and  
supporting interoperable implementations includes modifying the  
specification to allow implementation on a range of hardware  
architectures and system types, instead of just reflecting the  
attributes of the hardware on which it was initially implemented.

(3) The WG is expected to write "concrete protocol specifications".   
To me, this means that our documents should be complete, and represent  
IETF best practices for good protocol engineering.

(4) We are "NOT chartered to develop the final or standard solution".   
So, it would presumably be okay for there to be open issues in the  
LISP document (properly labeled and documented) when it is published  
as an Experimental RFC.   Ideally, we'd explore these areas during the  
experimentation phase, and document our findings in the analysis  
document.
> We used to have the ITR actually join the ALT, but then it had to  
> run BGP over

I understand that this was the history, but there are actually several  
advantages to having the xTR communicate with the mapping system as a  
service (rather than joining it).  One of the things that the WG is  
chartered to produce is a set of requirements for other mapping  
systems (other than the ALT), and I'd like to see us have a  
sufficiently abstract service interface between the xTRs and the  
mapping system that it is reasonable to swap out the mapping system,  
if necessary.

While I understand that having the ITR build an ALT packet and tunnel  
it to the Map Resolver provides some optimization for one current  
implementation of the Map Resolver, I don't think that is worth the  
loss of abstraction between the xTRs and the mapping system.  It is  
altogether possible that later implementations of Map Resolvers will  
be on servers, for example (perhaps side-by-side with a DNS server and  
a DHCP server?) where the additional encapsulation would have no value  
at all.

> some overwhelming evidence that what already works isn't going to

It is already done _in one implementation_ and it works.  That isn't  
all that important, IMO...

What we should be striving for is something that represents good  
protocol engineering, meets WG consensus, can work on a wide variety  
of systems, and is implemented in multiple interoperable  
implementations.  I am not interested in randomly invalidating  
existing code, but I strong object to valuing existing code in the  
Cisco implementation as highly as you imply.  I believe that anyone  
who implements a specification _before_ bringing it to an IETF WG  
should anticipate many rounds of significant changes to their code.   
Also, I think it is wrong to value the inconvenience of one set (or  
even a few sets) of early implementors over good protocol engineering,  
the ability to implement this specification efficiently on a wide  
variety of systems.

> even if it is in a different format.

You seem to be comparing the current text to a choice that isn't on  
the table any longer, having the ITR join the ALT.

Instead, you should be comparing two proposals for how ITRs will send  
Map-Requests:  Vince's proposal (with the Map-Request encapsulated in  
a new type of LISP control message) or Joel's proposal (with the Map- 
Request unencapsulated).

Also, the problem described in issue #22 is not about how hard (or  
easy) it is for the ITR to build the request, so I don't know why you  
are focusing on that.

The issue is about the trade-off between:

- The effort required by the MR to receive the request and send/ 
forward it onto the ALT.
- The effort required by the ETR to receive, process and respond to  
the request.

Vince's proposal makes things easier for the MR -- the MR receives an  
encapsulated ALT packet, and simply has to strip the outer header and  
forward the packet on the ALT.  With Joel's proposal, the MR would  
need to look at the contents of the Map-Request, in order to determine  
where to send it.  This requires
LISP-specific processing on the MR.  So, Vince's proposal requires  
less processing on MR's, and makes it significantly easier to  
implement an MR on a currently deployed BGP router with limited  
software changes.

Vince's proposal makes it harder to properly implement an ETR,  
though.  The ETR receives an encapsulated packet to the control port.   
It needs to do something to decapsulate that packet.  While this may  
seem simple, because it can just strip off the outer headers, it is  
not that simple to do this in a way that is RFC compliant, because the  
ETR also needs to do some checks on the inner header (such as checking  
the inner header IP address(es), IP checksum, UDP checksum and TTL  
fields) _before_ it processes the packet.  The easiest way to do this  
would be to pass the encapsulated packet back through the IP recieve  
portion of an IP stack, but that won't work with the packets in  
Vince's proposal, because the inner header is not addressed to the  
local stack, so the stack will throw the packet away.  So, it  
necessary to write LISP-specific code (or LISP-specific mods to the  
stack) to handle the inner IP/UDP headers.  Do you see why this is  
difficult?  Are these issues currently handled correctly in the Cisco  
implementation?  With Joel's proposal, the ETR receives an  
unencapsulated packet that is addressed to itself.

> LISP-specific code.  I find it very hard to understand how a LISP  
> map-request could be

I was responding to Dino's assertion that the MR/MS could currently be  
implemented with no LISP-specific code.   I will take your response as  
agreeing with me that Dino's assertion is incorrect.

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 24 Sep 2009 08:09:24 -0700

> though.  The ETR receives an encapsulated packet to the control  
> port.  It needs to do something to decapsulate that packet.  While  
> this may seem simple, because it can just strip off the outer  
> headers, it is not that simple to do this in a way that is RFC  
> compliant, because the ETR also needs to do some checks on the inner  
> header (such as checking the inner header IP address(es), IP  
> checksum, UDP checksum and TTL fields) _before_ it processes the  
> packet.  The easiest way to do this would be to pass the  
> encapsulated packet back through the IP recieve portion of an IP  
> stack, but that won't work with the packets in Vince's proposal,  
> because the inner header is not addressed to the local stack, so the  
> stack will throw the packet away.  So, it necessary to write LISP- 
> specific code (or LISP-specific mods to the stack) to handle the  
> inner IP/UDP headers.  Do you see why this is difficult?  Are these  
> issues currently handled correctly in the Cisco implementation? With  
> Joel's proposal, the ETR receives an unencapsulated packet that is  
> addressed to itself.

Like I already mentioned, the outer header is processed by the  
protocol stack. The destination is addressed to the ETR. The  
destination port of 4342 causes the socket layer to deliver the packet  
to the LISP client. The LISP client then parses the packet.

You do not have to take the inner header and give it back to the  
protocol stack. That makes for a more complicated implementation.

The prototype implementation can handle this fine and the code has  
been running for at least 6 months this way.

Dino

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 24 Sep 2009 11:24:49 -0400

> been running for at least 6 months this way.

Do you mean your/Cisco's implementation?  Or is "the prototype  
implementation" something else?

Does your implementation perform the following checks on the inner  
packet:

- Check the IP header version
- Check the IP header checksum
- Check the UDP checksum
- Process any IP options/extension headers that might affect  
processing of this packet
- Check the TTL, and return an ICMP error if it is expired

Although I realize it is possible to do these checks in my LISP code,  
I'd personally prefer to have this type of checking and error handling  
performed by the IP stack, which would be possible with Joel's  
proposal and not with Vince's.  That would make an ETR easier to  
implement.

I think this is similar to your desire to make an MR easier to  
implement, by allowing it to just decapsulate and send the Map- 
Request, without having to parse any of the Map-Request fields.   
Obviously you _know how_ to write code that can parse the Map-Request  
fields, you would just prefer not to do it in the MR.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 24 Sep 2009 11:32:56 -0400

One more question...  What do you do if the inner header indicates  
that the packet has been fragmented?

Margaret

On Sep 24, 2009, at 11:24 AM, Margaret Wasserman wrote:

> Although I realize it is possible to do these checks in my LISP  
> code, I'd personally prefer to have this type of checking and error  
> handling performed by the IP stack, which would be possible with  
> Joel's proposal and not with Vince's.  That would make an ETR easier  
> to implement.
>
> Obviously you _know how_ to write code that can parse the Map- 
> Request fields, you would just prefer not to do it in the MR.
>
> Margaret
>
>
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 24 Sep 2009 08:45:39 -0700

> implementation" something else?

The implementation written by cisco employees yes.

> - Check the IP header version

Yes.

> - Check the IP header checksum

Yes.

> - Check the UDP checksum

Yes.

> processing of this packet

Doesn't process options because the Map-Request is sent with no  
options (and spec'ed that way). So if options are received, we jump  
over them to get to the UDP header.

> - Check the TTL, and return an ICMP error if it is expired

Since the inner TTL is copied to the outer TTL and the packet was  
received by the ETR (i.e. the unencapsulated Map-Request traveled  
through the ALT before the TTL went to 0) it accepts it. When the  
packet is received with a TTL of 0, it accepts it (i.e. if the  
destination EID matches one of the local EID-prefixes).

> Joel's proposal and not with Vince's.  That would make an ETR easier  

Well that is fine if you have a preference, but this shouldn't be a  
show-stopper for the mechanism.

Please note all the features we could lose if we do the Joel proposal.  
I outlined that in a previous email a couple days ago.

The Joel proposal doesn't have sufficient detail to evaluate the  
features I outlined will still be supported.

> implement, by allowing it to just

That is a positive point but that isn't my main desire. The main  
desire is to give the user the ability to use different vendor  
equipment on the ALT.

And let me repeat, putting an EID in the destination field does not  
make assumptions that ALT is used for the mapping database mechanism.  
The key for a "table lookup" for any kind of database mechanism is in  
the IP header. It makes it convenient for the mapping database system  
to access that key.

Please note, the priority here are the features the current design is  
providing for the network and the dominant point shouldn't be to make  
easier implementations. Yes, we want the implementations to be easier  
to implement but not at a cost of losing services.

> decapsulate and send the Map-Request, without having to parse any of  
> the Map-Request fields.  Obviously you _know how_ to write code that  
> can parse the Map-Request fields, you would just prefer not to do it  
> in the MR.

Right, so you are concluding that the differences are minimal from an  
implementation point of view. But we don't know how the new proposal  
can deliver the services the current design can provide.

Dino