Subject: [lisp] comments and questions on draft-ietf-lisp-11

From: Alia Atlas <[email-masked]>
Date: Wed, 20 Apr 2011 11:40:28 -0400

1. For instance, a mapping service is required – but the role and
assumptions for that mapping service are never described.   The Packet
Flow Sequence (4.1) was helpful, but doesn’t contain enough details to
be clear.  Who are the LISP Map-Requests sent to?  How is this known?

2.	The idea of using LISP for traffic-engineering is scattered through
the draft, but there is no clear example or description of how to do
so.    This also applies to the use of anycast.

3.	On p. 9,  it specifies for the EID-to-RLOC Database that “the same
database mapping entries MUST be configured on all ETRs for a given
site.”   Later in the draft, it is said that they can be transiently
different – but what is the impact there?  How is/should a
misconfiguration be detected much less enforced?  What are the
consequences of a misconfiguration & how would an operator deal with
it?

4.	How is looping prevented when doing re-encapsulation of packets?
What safety measures exist to prevent/minimize looping when there are
transient EID-to-RLOC mappings?  Obviously, TTL helps eventually to
discard packets, but that isn’t sufficient.

5.	Why is there no definition for the RLOC to be IPv4 while the EID is
IPv6 or vice versa??  In Section 9, traceroute talks about it – but it
isn’t defined.  As I understand the potential uses of LISP, an idea is
to v6 in v4 automatic tunneling & vice versa – so it’s very strange to
me that those packet formats aren’t defined.

6.	On p.23 in the 2nd to last paragraph, it seems that an ETR MUST do
fragment reassembly (at line rate) just in case the ITR (or an
attacker) chooses to set the DF bit to 0 and there is an MTU issue?
That isn’t explicitly specified as a MUST – but the rest of the
language makes it pretty clear that’s the case?  I really don’t
understand the reasoning for this.  Wouldn’t it be much cleaner and
easier for the ITR to fragment packets when it encapsulates them?
Forcing reassembly at the ETR requires queuing of the packets and
makes more attack vectors and complications…

7.	For the virtualization/segmentation, how is the Source-EID AFI &
Source EID Address of use in the Mapping Request?  If there can be
multiple instances behind an RLOC, doesn’t an instance ID need to be
there also?   This area seems slightly described in the draft for the
traffic, but not for learning mappings.

8.	Sec 6.1.3, “For the initial case, the destination IP address used
for the Map-Request is the destination-EID from the packet which had a
mapping cache lookup failure.  For the latter 2 cases, the destination
IP address used for the Map-Request is one of the RLOC addresses from
the locator-set of the map cache entry.”   How is the receiver of the
Map-Request supposed to know whether an EID or RLOC is being used?!?

9.	On p.33, the Record TTL specifies how long the entry is stored???
How does that go with the cache being locally managed?   Having it be
the length of time that the mapping is good for makes some sense.

10.	Related to the Record TTL & cache storage, the description of how
to handle mappings and expirations needs much better description.  A
single case where a prefix has more specific prefixes that route
differently is shown – but not the implications of handling that as
more mappings are added and removed.  I think this is largely a
question of better language.  However, it is also unclear how an ITR
doing cache management knows which entries to remove and the
connections between them.    Related, would an ETR announce mappings
for instance for 3  /24 instead of the /23 and one exception /24?
What if the ETR doesn’t own the exception /24?  I think more policy
and explanation is really needed here.

11.	If the cache is “locally managed”, then a good description of the
rules that the cache MUST follow should be in the draft.   There
clearly are some and the issues are scattered.

12.	 I suspect that I can get more context from other LISP drafts (and
plan to do so), but I don’t see how the mapping service isn’t a
normative reference?   I feel like there should be a framework draft –
perhaps the individual deployment draft is intended in its place??

Perhaps it is because this is intended to be experimental, but I find
the draft, writing, and consistency to be significantly rough compared
to what I’d expect for a draft about to enter WG last call.

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 21 Apr 2011 10:29:46 +0200

Hi Alia,

and a good day to you as well.

I have a couple of answers/comments inline.

ciao

Luigi

> be clear.  Who are the LISP Map-Requests sent to?  How is this known?

In point 2 of the example it is clearly stated that the specific method is not described in the example itself.
For that example you can think to the mapping system as a black box that you can query in order to retrieve the needed mappings.

> so.    This also applies to the use of anycast.

The draft is about protocol specification not about the use/deployment of LISP, hence IMHO there is no need to go deep in the TE topic. Even the deployment draft cannot be IMO exhaustive on that topic. How to do TE is up to the operators.

> consequences of a misconfiguration & how would an operator deal with

There is no use in document this. Is impossible to document all possible misconfigurations, their consequences,  and their fixes.
This applies also to your next point.

> me that those packet formats aren’t defined.

Your EIDs and RLOCs can be anything. Why the specs should define EID in IPv6 and RLOCs in IPv4? A very nice feature of LISP is that you can mix protocol families, having v4 on v6 or viceversa, beside the v6 on v6 and v4 on v4.

Concerning the packet format, there is no use in adding all possible cases in the specs. The text is sufficiently clear on how to build packet in all cases.

> fragment reassembly (at line rate)

Not true. It is clearly stated that ETR treats the packet independently and does not perform reassembly.

> just in case the ITR (or an

Which is what the specs actually say. You can store for TTL time the mapping, then you have to refresh if you still want to use it. The cache management is local.

> and explanation is really needed here.

How can you have the right to origin a mapping announce of a /23 when you own only a part of it?? 

> rules that the cache MUST follow should be in the draft.

I totally disagree. This is an implementation issue.

>   There
> normative reference?

References will be re-organized before going for LC.

Luigi

>   I feel like there should be a framework draft –
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Alia Atlas <[email-masked]>
Date: Thu, 21 Apr 2011 17:31:26 -0400

Hi Luigi,

I appreciate your response, though I would have preferred more answers
and fewer assertions.   I fully intend to read the mapping service and
deployment drafts - but they are not listed as normative references
and I found this draft lacks adequate clarity to determine the
completeness or accuracy of the protocol.

My responses are, of course, in-line.

Alia

On Thu, Apr 21, 2011 at 4:29 AM, Luigi Iannone
<[email-masked]> wrote:
> For that example you can think to the mapping system as a black box that you
> can query in order to retrieve the needed mappings.

[Alia] I do not need the Mapping Service to be defined here.  I am
looking for a brief description of what a mapping service is.  I'm
looking for the black-box architectural definition of a Mapping
Service - not the white-box or internal detailed description.

Without such a definition, I can only see the Mapping Service as an
Oracle - and the interactions between the ITR and ETR are not clear.

> The draft is about protocol specification not about the use/deployment of
> LISP, hence IMHO there is no need to go deep in the TE topic. Even the
> deployment draft cannot be IMO exhaustive on that topic. How to do TE is up
> to the operators.

[Alia] I am more familiar with OSPF/ISIS/MPLS specifications and their
completeness.  Just because this is experimental doesn't mean that it
shouldn't be clearly enough defined to be comprehensible and
understood.

I am looking for something that pulls out and describes briefly what
TE is meant or intended.  I understand, of course, that by providing
different RLOCs for various EIDs one can direct traffic in different
directions.  A few examples would aid comprehension substantially.

> There is no use in document this. Is impossible to document all possible
> misconfigurations, their consequences,  and their fixes.

[Alia] A protocol exists in a network with operators.  From reading
this draft, it is NOT
clear what the consequences of misconfiguration are nor how they would
be detected.  Is it simply that traffic may be routed differently
depending upon which ETR a Map-Reply is heard from?  Is it that
traffic will oscillate between the different answers provided by the
ETRs?

> discard packets, but that isn’t sufficient.

[Alia] Where and how is consistency guaranteed by LISP?  This is not a
misconfiguration
question!  Looping is traditionally avoided in overlay networks by
staying in the overlay network.  With MPLS-TE, LSPs can be advertised
into the IGP as adjacencies that are then considered by the IGP's SPF
computation.

>From this draft, I cannot clearly tell either when re-encapsulation of
packets is required nor how and when looping is prevented.  In
OSPF/ISIS, the opportunity for loops are well understood and occur
only during convergence times.

LISP doesn't explicitly have convergence...

> Your EIDs and RLOCs can be anything. Why the specs should define EID in IPv6
> and RLOCs in IPv4? A very nice feature of LISP is that you can mix protocol
> families, having v4 on v6 or viceversa, beside the v6 on v6 and v4 on v4.
> Concerning the packet format, there is no use in adding all possible cases
> in the specs. The text is sufficiently clear on how to build packet in all
> cases.

[Alia] No text in Section 5 indicates that the 2 encapsulations
defined clearly (IPv4 in IPv4 and IPv6 in IPv6) are not the only ones
to be supported.  Do you feel that the claim that there is an outer
header and an inner header is sufficient?

A specification must be implementable - and inter-operate.  Without
even trivial definitions of packet formats or the statement of the set
that can exist, I am dubious that this draft gives the necessary
detail.  Please remember that the goal is not for only those actively
collaborating on LISP specifications to be able to read and understand
the drafts.

Obviously, I can infer how to build IPv6 in IPv4 and vice versa - but
the explicit statement of the two formats that are supported and the
fact that the others are not there strongly implies that they should
not be supported or expected.

> does not perform reassembly.

[Alia] If the ITR takes a packet, encapsulates it with an outer
header, and then sends it with DF=0 through a network that fragments
that packet - either the ETR must do reassembly or only the first
fragment will make it to the destination host and be discarded
eventually when no second (or further) fragments are received.  The
intermediate router that fragments the packet will not be LISP-aware
or know to add an inner header to the second (or further) fragments.
Please explain how this is not the case - since it is clearly stated
that the ITR can set DF=0.

> Which is what the specs actually say. You can store for TTL time the
> mapping, then you have to refresh if you still want to use it. The cache
> management is local.

[Alia] No, that is not what the spec says.  It says

"Record TTL:  The time in minutes the recipient of the Map-Reply will
      store the mapping.  If the TTL is 0, the entry SHOULD be removed
      from the cache immediately.  If the value is 0xffffffff, the
      recipient can decide locally how long to store the mapping."

That doesn't sound like local cache management to me.  The sender is clearly
specifying to the receiver how long to store the mapping - and there's
even a value
given the recipient control on how long to store the mapping.

> question of better language.
>
>  However, it is also unclear how an ITR
> connections between them.
>
>  Related, would an ETR announce mappings

[Alia] That makes sense - pity there isn't clarification in the draft.
 I found the section on needing multiple prefixes to be returned for a
mapping to be rather challenging to understand the intent.  I'm also
concerned for cache management on how it handles not knowing how much
space a new mapping may require.

I am having a hard time understanding how LISP with its caches isn't
just a victim waiting for an attack - but I guess the theory is that
it is experimental so it and alternatives can be played with.

> I totally disagree. This is an implementation issue.

[Alia] So it is an implementation issue if my cache runs out of space
and can only store 2 of the 4 prefixes that are sent in response to a
mapping?  It is an implementation issue if I decide to purge a prefix
that was actually a hole in a larger prefix?  It is an implementation
issue if I ignore the Record TTL and pitch mappings after 5 minutes?

> References will be re-organized before going for LC.
[Alia]  That may help.  I know that there are implementations of LISP
- but I find the lack of clarity and details on issues around
liveness, looping, and so on to be distinct challenges to interop and
safe operation.

Alia

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 22 Apr 2011 11:17:23 +0200

Hi Alia,

On Apr 21, 2011, at 11:31 PM, Alia Atlas wrote:

> and fewer assertions.  

Oscar Wilde said: "Be careful what you wish for, it might come true" ;-)

Let me try to provide some answer inline. 

 [snip]
> Oracle - and the interactions between the ITR and ETR are not clear.

IMHO the text is sufficient for the example. You can safely consider the mapping system as an oracle for the that specific example.

> directions.  A few examples would aid comprehension substantially.

IMHO the text is already there and examples are also there when appropriate with the context.

> traffic will oscillate between the different answers provided by the

I still do not see why we should document all of these cases. First because is impossible to document all of them, second because we would document only what we think would happen. It does not buy you anything. 

> LISP doesn't explicitly have convergence...

Has been proved that BGP does not have convergence neither... it still works.

But what exactly is your point here?

[snip]

> not be supported or expected.

As an implementor even if those packets format would be defined in the document I would skip reading them. 

Why you say that it implies that they should not be supported or expected? 

The text clearly says that it is not worth to provide pictures for every single case.

> that the ITR can set DF=0.

Got your point. The example you make is correct. But in the original text there is a SHOULD, is not enough for you?

[snip]

> given the recipient control on how long to store the mapping.

The text says how long the mapping is valid. 

1) TTL = 0xffffffff you keep the mapping as long as you wish (consider it always valid).
2) TTL = X : the mapping is valid only X period of time. When this time is expired you SHOULD not use the mapping, hence you SHOULD delete it from your cache otherwise your forwarding engine will use it.

[snip]
> it is experimental so it and alternatives can be played with.

I am not sure if you refer to security issues here, for that there is a different document.

> mapping?  

Yes. Choose your replacement algorithm.

> It is an implementation issue if I decide to purge a prefix
> that was actually a hole in a larger prefix?  

What do you mean by "hole"?

> It is an implementation

You are not respecting the protocol and I do not see your point here.

[snip]

Luigi