Subject: [lisp] Warren Kumari's Discuss on draft-ietf-lisp-rfc6830bis-26: (with DISCUSS and COMMENT)

From: Warren Kumari <[email-masked]>
Date: Tue, 05 Feb 2019 18:21:54 -0800

Warren Kumari has entered the following ballot position for
draft-ietf-lisp-rfc6830bis-26: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I read much of this on a plane while overtired, so it is entirely possible /
probable that I've completely misunderstood something(s) obvious. Many of the
below are probably simple to address, and either I simply need to be educated,
or just there needs to be a bit more text / detail provided.

1: "3.  The ITR sends a LISP Map-Request as specified in
[I-D.ietf-lisp-rfc6833bis].  Map-Requests SHOULD be rate-limited." What does
the ITR do with the packet while waiting for the Map-Request to complete? Must
it buffer the packets or can it discard them? If the former, for how long must
it buffer? When you say "SHOULD be rate-limited", can you provide guidance on
rates? 1 request per second? 1 million per second? Is this rate-limit per
destination or per device? Apologies if this is clearly stated in RFC6833(bis)
- I only skimmed it, and didn't see an answer there.

2: "6. ... Note that the Map-Cache is an on-demand cache. An ITR will manage
its Map-Cache in such a way that optimizes for its resource constraints."
Presumably I could cause this cache to thrash / overflow by looking at the RLOC
database, and choosing EIDs to send traffic to which all require different
cache entries, causing the cache to overflow (or, at least, causing maximum
cache pressure). This seems like an ideal DoS vector. It seems that there
should be more guidance provided on how to size the Map-Cache / the expected
order of the cache size, even if it is ultimately an implementation issue (e.g:
is a Map-Cache of 100 entries OK for an ITR? or should it be O(1000)? Or
roughly size(database)/2? Having multiple devices with small caches, and a bot
which does the above seems like a global risk).

I'm quite confused by much of the MTU / Fragmentation stuff -- I did read the
documents on a plane after not getting much sleep, and so it is entirely
possible / probable that I'm just being stupid, but there are bits which don't
seem to make sense to me. 3: "2.  Define L to be the size, in octets, of the
maximum-sized packet an ITR can send to an ETR without the need for the ITR or
any intermediate routers to fragment the packet." How do I know what L is? The
document "RECOMMENDS that L be defined as 1500" -- but 1500 isn't universally
true (if it were, we would never have to do Path MTU). What happens when the
*actual* MTU on the path is e.g 1476 because there is a tunnel on the path? The
text also mentions "which is less than the ITR’s estimate of the path MTU
between the ITR and its correspondent ETR" - this implies that the ITR is
tracking / estimating the MTU, which a: doesn't align with the rest of the
text, or b: sounds like the stateful solution below. I have reread this
multiple times, but it still feels like it is avoiding the issue by defining it
to not exist.

4: "Note that reassembly can happen at the ETR if the encapsulated packet was
fragmented at or after the ITR." - I think that there needs to be more text /
description about resource constraints on routers performing reassembly of
fragments - in most cases a router doesn't have to / isn't expected to have to
reassemble transit packets from arbitrary sources on the Internet (things where
routers may reassemble are aimed at the control plane which can be
rate-limited, or are from expected source addresses). It seems that spoofing
lots of initial fragments without the final one will be a tax on the router.

5: "Instead of using the Map-Cache or mapping system, RLOC information MAY be
gleaned from received tunneled packets or Map-Request messages. A "gleaned"
Map-Cache entry, one learned from the source RLOC of a received encapsulated
packet, is only stored and used for a few seconds, pending verification." - it
seems that this is ripe for abuse (or I'm missing in the cache expiration). I
want to hijack traffic from Site X to well known Service Y, so I look up
Service Y and save the TTL from the Map-Reply. I then start spoof packets
listing myself as the ETR - eventually Site X will glean from my spoofed
packets, and start sending traffic to me - yes, this will only work for a few
seconds -- but as soon as I stop getting packets from site X, I know site X has
verified the entry and discovered it is wrong... and that the TTL is now being
deprecated. I start a timer, and second or two less than the TTL later I start
spoofing packets again, knowing that site X will soon expire the cache entry
and will once again be willing to accept mine again. A: I get some Site X to
Site Y traffic for a few seconds every TTL seconds, and B: the loss of this
traffic is a signal that TTL seconds again it will need to be refreshed.

 6: "10.1.  Echo Nonce Algorithm" -- If I spoof lots of packets with the N- and
 E-bits set, the receiving ETR will need to keep false state, and presumably I
 can overfill a cache. This will cause the ETR to not be able to include the
 received nonce on legitimate traffic, and so the ITR on the far side will
 think this ETR is down. This seems like a fairly easy DoS. I'm guessing that
 this can be worked around by not setting the E bit in the RLOC-probe Map-Reply
 message, but this feels like a dangerous foot gun, and should at least be
 noted. Note that this is different to the "Note the attacker must guess a
 valid nonce the ITR is requesting to be echoed within a small window of time. 
 The goal is to convince the ITR that the ETR’s RLOC is  reachable even when it
 may not be reachable."  attack listed in the document in that a: it doesn't
 require any guessing, and b: makes an ETR appear down, not up.

The document does mention "... attack can be mitigated by preventing RLOC
spoofing in the network by deploying uRPF BCP 38 [RFC2827]." - while that may
be true for many of the above, BCP38 is far from being universally deployed,
and this feels similar to solving world hunger by saying everyone must have
enough food. :-)

Again, apologies if I've completely misunderstood something, clue-bat gladly
accepted...

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Comments:
1: "LISP Locator-Status-Bits (LSBs):  ... The field is 32 bits when the I-bit
is set to 0 and is 8 bits when the I-bit is set to 1." - I think I'm missing
something fairly fundamental here (and in Section 10, 13.1, and others) - if
I'm using the I bit, it sounds like I can only have 8 ETRs? And with this clear
I can only have 32? I feel like I must have missed something....

2: "When the ’DF’ field of the IP header is set to 1, or the packet is an IPv6
packet originated by the source host, the ITR will drop the packet when the
size is greater than L and send an ICMPv4..." I think this needs to say when
the resulting (or encapsulated) packet is greater than L (otherwise it is
unclear if you are referring to the original or resulting packet).

3: "The server-side sets a Weight of zero for the RLOC subset list. In this
case, the client-side can choose how the traffic load is  spread across the
subset list." -- please insert a reference to Section 12 here. I wrote up a
long comment on what happens of the load sharing delivers packets to different
ETRs, before finding this section later on in the document.

Nits:
1: " LISP does not require changes to either host protocol stack or to underlay
routers. " -- I think either "to either the host protocol stack" or " to either
host protocol stacks"

2: "As an exmple of such attacks an off-path attacker can" -- typo for example.

3: "it can protect itself from erroneious reachability attacks" -- typo for
erroneous.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 6 Feb 2019 09:48:06 -0800

Warren, thanks for the review, I have changed text to address your comments and nits below. A new diff file is enclosed at the end.

I want to send one message to the IESG. This has no reflection on Warren or his commentary. But the standards process seems to be at an all-time low for my prespective. And this Jan 2019 I have been coming to IETF for 30 years. So I think I’m not speaking off the cuff here and speak from what I have experienced over that long time frame.

We have been trying to get these documents to move forward and it seems with all the new people that come to the IESG that do the reviews are not expert in the art and hence we have to explain basic LISP. It has been happening for about 6 quarters now. We explain, people understand, a quarter passes, there is silence, new people come into the review process, and we explain again.

We have redone text so many times that likely have undone commentary from people that were experienced in the art who commented years ago. What if they come back in now and say “you change the text again”.

To the authors, this seems non-sense, never ending and not productive. One can see why open-source approaches are out competing the IETF process. I’ll stop there.

I’ll explain once again in the DISCUSS comments below because I know Warren put effort into this when he should have been resting.  ;-)

> On Feb 5, 2019, at 6:21 PM, Warren Kumari <[email-masked]> wrote:
> 

I will respond briefly and directly.

> - I only skimmed it, and didn't see an answer there.

We have said drop or queue. We discourage queuing because one never knows which packets are the important ones to queue. Never much the same as the ARP resolution issue.

> which does the above seems like a global risk).

What happens if you send 10,000,000 BGP routes in an update and the receiver can’t store it. It is the same problem. We have lots of research on this problem and there are pointers in the spec to it.

> multiple times, but it still feels like it is avoiding the issue by defining it

L is an architectural constant. If there tends to be tunnels between the ITR and ETR, then you choose L to be 1400. Or you run MTU discovery between the ITR and ETR to determine the effective MTU.

> lots of initial fragments without the final one will be a tax on the router.

We have chosen 3 methods to deal with MTU issues because ETR reassembly is the worst approach. And I certainly wouldn’t recommend using it.

> traffic is a signal that TTL seconds again it will need to be refreshed.

It was a Google employee in the early days that wanted this feature (circa 2007). ;-) It was so return packets from a server side didn’t have to do the mapping system lookup. It is off by default and only used in trusted enviornments where you can control how the ITR and ETR behave.

> require any guessing, and b: makes an ETR appear down, not up.

You can’t overfill any cache. An xTR just remembers the last nonce that came with the E-bit set and when it returns packets it uses that nonce.

Yes, many implementations default to not setting advertising they are echo-nonce capable in Map-Replies. So RLOC-probing tends to be used for RLOC reachability. Plus we added features into RLOC-probing that makes it more useful now (lisp-crypto key exchange for one).

> and this feels similar to solving world hunger by saying everyone must have

An ETR can verify mappings if it chooses to. The more overhead you want to put in the system for anti-spoofing, one can do. Tradeoffs.

By the way food is everywhere, you just have to be willing to eat it.  ;-)

> accepted…

You did a pretty good job. Thanks.

> I can only have 32? I feel like I must have missed something….

Right 8 ETRs per EID-prefix. If you needed more, then you take the EID-prefix and cut it in half and increase the mask-length by 1, then you can use a different set of 8 for each more specific EID-prefix. Otherwise, you use RLOC-probing and the number of RLOCs can bee up to 255 (the width of the RLOC-Count field in an EID-record).

> unclear if you are referring to the original or resulting packet).

Yes, I will clarify. Great point.

> ETRs, before finding this section later on in the document.

Done.

> 3: "it can protect itself from erroneious reachability attacks" -- typo for

Fixed.

Thanks again,
Dino

---

From: Warren Kumari <[email-masked]>
Date: Wed, 6 Feb 2019 14:00:35 -0500

On Wed, Feb 6, 2019 at 12:48 PM Dino Farinacci <[email-masked]> wrote:

> Warren, thanks for the review, I have changed text to address your
> comments and nits below. A new diff file is enclosed at the end.
>
> I want to send one message to the IESG. This has no reflection on Warren
> or his commentary. But the standards process seems to be at an all-time low
> for my prespective. And this Jan 2019 I have been coming to IETF for 30
> years. So I think I’m not speaking off the cuff here and speak from what I
> have experienced over that long time frame.
>
> We have been trying to get these documents to move forward and it seems
> with all the new people that come to the IESG that do the reviews are not
> expert in the art and hence we have to explain basic LISP. It has been
> happening for about 6 quarters now. We explain, people understand, a
> quarter passes, there is silence, new people come into the review process,
> and we explain again.
>
> We have redone text so many times that likely have undone commentary from
> people that were experienced in the art who commented years ago. What if
> they come back in now and say “you change the text again”.
>
> To the authors, this seems non-sense, never ending and not productive. One
> can see why open-source approaches are out competing the IETF process. I’ll
> stop there.
>
> I’ll explain once again in the DISCUSS comments below because I know
> Warren put effort into this when he should have been resting.  ;-)
>
> We have said drop or queue. We discourage queuing because one never knows
> which packets are the important ones to queue. Never much the same as the
> ARP resolution issue.
>

Works for me -- note that I don't see that in either the original, nor the
attached diff.

> What happens if you send 10,000,000 BGP routes in an update and the
> receiver can’t store it. It is the same problem. We have lots of research
> on this problem and there are pointers in the spec to it.
>

Well, what happens is that I tear down the session:
accepted-prefix-limit {
      maximum {{ peer_prefix_limit }};
      teardown 85 idle-timeout 10;
}

This is somewhat of a false analogy - I only accept BGP routes from
configured peers, not just anyone on the Internet.
A better analogy would be Neighbor Discovery, where a random person on the
Internet can cause your router to have to build state -- and we ended up
having to publish RFC6583 - "Operational Neighbor Discovery Problems" to
address exactly this issue.

> L is an architectural constant. If there tends to be tunnels between the
> ITR and ETR, then you choose L to be 1400. Or you run MTU discovery between
> the ITR and ETR to determine the effective MTU.
>

That doesn't sound like an "architectural constant" - it sounds like a
configurable value.
As an example:
"Both OSPF and IS-IS make a clear distinction between architectural
constants and configurable parameters. Architectural constants are
parameters which were fixed by the specification and cannot be changed by
the network manager".
(from "OSPF and IS-IS: From Link State Routing Principles to Technologies").
See also https://tools.ietf.org/html/rfc2328#appendix-B ,
https://tools.ietf.org/html/rfc3719, etc.

> We have chosen 3 methods to deal with MTU issues because ETR reassembly is
> the worst approach. And I certainly wouldn’t recommend using it.
>

Fair, but I think the document should say so.

> It was a Google employee in the early days that wanted this feature (circa
> 2007). ;-) It was so return packets from a server side didn’t have to do
> the mapping system lookup. It is off by default and only used in trusted
> enviornments where you can control how the ITR and ETR behave.
>

You say that "it is off by default" -- but I don't see that in this
document (nor, at a quick glance, in RFC 7832 - "Locator/ID Separation
Protocol (LISP) Threat Analysis").

> You can’t overfill any cache. An xTR just remembers the last nonce that
> came with the E-bit set and when it returns packets it uses that nonce.
>

Um, I don't think this is right (or I've misunderstood) - you don't store
"the last nonce that came with the E-bit set" (one number), you have to
store "the last nonce that came with the E-bit set for every ITR which is
sending them".
These have to be stored somewhere, and this is a limited size space (N
slots). If I send you N+1 spoofed packets you will have to evict something
from this space -- what am I missing?

>
> Yes, many implementations default to not setting advertising they are
> echo-nonce capable in Map-Replies. So RLOC-probing tends to be used for
> RLOC reachability. Plus we added features into RLOC-probing that makes it
> more useful now (lisp-crypto key exchange for one).
>
>
Pointer?

> An ETR can verify mappings if it chooses to. The more overhead you want to
> put in the system for anti-spoofing, one can do. Tradeoffs.
>

As someone who was born in Africa and has seen the effects of famine
firsthand, I find this statement offensive -- people don't starve to death
because they didn't feel like eating their broccoli, they starve to death
because there isn't any food.

W

> Right 8 ETRs per EID-prefix. If you needed more, then you take the
> EID-prefix and cut it in half and increase the mask-length by 1, then you
> can use a different set of 8 for each more specific EID-prefix. Otherwise,
> you use RLOC-probing and the number of RLOCs can bee up to 255 (the width
> of the RLOC-Count field in an EID-record).
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 6 Feb 2019 14:06:23 -0500

Hi Dino,

> On Feb 6, 2019, at 12:48 PM, Dino Farinacci <[email-masked]> wrote:
> 

Thanks for sharing your view with us.

> We have been trying to get these documents to move forward and it seems with all the new people that come to the IESG that do the reviews are not expert in the art and hence we have to explain basi…

The full history of the processing of this document is available at: <https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/history/>. As you can see, IESG processing of this document began in September 2018, a little less than 5 months ago. The exact same IESG members were balloting on the document then as are balloting now since there has been no turnover in the IESG between now and then.

Of course, the full WG and IETF review processes have extended further into the past than that. Part of the point of standardizing in the IETF is to obtain cross-area input from those who may have expertise, but not necessarily expertise in dealing with the protocol being specified. If there was no interest in getting cross-area review for LISP, it shouldn’t have been put forth on the IETF standards track. And part of the value of IESG review in particular is to determine if an independent implementer could pick up the spec and produce an interoperable implementation with those written by, say, the spec authors. The DISCUSS criteria are available here: <https://www.ietf.org/blog/discuss-criteria-iesg-review/>.

For this document and its companions in particular, there has been more back-and-forth with the IESG than is typical. Clearly many of us are not LISP experts and we appreciate the insights that you and your co-authors have shared to help us understand the protocol better. We also had holidays intervene to lengthen the review process. But typically our engagements with authors are also more comprehensive: authors implement agreed-upon changes fully and in a single or small number of revs so that it’s easy to re-evaluate the document, the authors check for internal consistency between inter-dependent documents before posting revs, and the answers they provide in email offer specific pointers to text or list discussion to back up their arguments. The re-review process for these documents has suffered from a lack of this kind of engagement, in my opinion. 

> We have redone text so many times that likely have undone commentary from people that were experienced in the art who commented years ago. What if they come back in now and say “you change the text…

IETF work is based on the consensus of people present. Hopefully the changes being made in this round will not require sending these documents back for another WG consensus call. But if they do, the question is whether the people engaged now want the documents published as-is. That is the best that we can do.

> To the authors, this seems non-sense, never ending and not productive. One can see why open-source approaches are out competing the IETF process. I’ll stop there.

In many cases open source and open standards aren’t really even adversarial to one another. But it’s true that if what you were after was an open source implementation, or a process where a limited set of contributors could decide on an implementation design, an IETF standard is not a good fit for that.

> I’ll explain once again in the DISCUSS comments below because I know Warren put effort into this when he should have been resting.  ;-)

The IESG typically processes 300-400 pages of IETF documents every two weeks. From what I’ve seen it is a hard working group that puts in a tremendous amount of effort to do a job that is important for the Internet but mostly thankless.

Alissa

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 6 Feb 2019 11:30:44 -0800

> The full history of the processing of this document is available at: <https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/history/>. As you can see, IESG processing of this document began i…

Rather than questioning my accuracy of the past, don’t lose the point of the comment. From my point of view, this has gone on for 1.5 years. Just this last epoch review. Note the working group started in 2009.

> For this document and its companions in particular, there has been more back-and-forth with the IESG than is typical. Clearly many of us are not LISP experts and we appreciate the insights that you and your co-authors have 

And why do you think that has been the case?

> shared to help us understand the protocol better. We also had holidays intervene to lengthen the review process. But typically our engagements with authors are also more comprehensive: authors implement agreed-upon changes fully and in a single or small number of revs so that it’s easy to re-evaluate the document, the authors check for internal consistency between inter-dependent documents before posting revs, and the answers they provide in email offer specific pointers to text or list discussion to back up their arguments. The re-review process for these documents has suffered from a lack of this kind of engagement, in my opinion. 

Well the reviewers don’t have the history of the past nearly 12 years this effort has gone on for. So we can’t just change fully or else we disrespect the reviewers that have commented from the past. Not to mention implementations that have been around or 7 years and deployments in place.

We really want an IETF document to reflect reality.

> IETF work is based on the consensus of people present. Hopefully the changes being made in this round will not require sending these documents back for another WG consensus call. But if they do, th…

I remember working at cisco when we had to build chips for next-generation routers. Estimates indicated that it would take 5 years to build for a new cutting edge next-generation tech. If it takes that long, then when you release you have an obsolete product.

I fear this is what is happening to this document series. I am trying to avoid that and hence some push back on changing text that was agreed upon many times and many years ago.

> In many cases open source and open standards aren’t really even adversarial to one another. But it’s true that if what you were after was an open source implementation, or a process where a limited…

Adversarial is not the right word I think. More people are going to open-source projects than building technology through SDOs. This should be totally obvious.

> The IESG typically processes 300-400 pages of IETF documents every two weeks. From what I’ve seen it is a hard working group that puts in a tremendous amount of effort to do a job that is important…

Yes, I understand the load. So it would seem the IESG would want to close issues quicker.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 6 Feb 2019 11:41:29 -0800

> This is somewhat of a false analogy - I only accept BGP routes from configured peers, not just anyone on the Internet. 
> A better analogy would be Neighbor Discovery, where a random person on the Internet can cause your router to have to build state -- and we ended up having to publish RFC6583 - "Operational Neighbor Discovery Problems" to address exactly this issue.

I don’t think it is. Because a BGP table and a cache is still allocable memory that has to be managed. And it doesn’t matter if peers are configured or not, a bad peer can still damage a BGP cache.

And those limits can be placed on the LISP table as well.

> That doesn't sound like an "architectural constant" - it sounds like a configurable value.
> As an example: 
> "Both OSPF and IS-IS make a clear distinction between architectural constants and configurable parameters. Architectural constants are parameters which were fixed by the specification and cannot be changed by the network manager". 
> See also https://tools.ietf.org/html/rfc2328#appendix-B , https://tools.ietf.org/html/rfc3719, etc. 

Was the changed text sufficient?

> Fair, but I think the document should say so. 

I don’t think it should. If someone has ETR resources to do so, it should be able to do it. Fragmentation/assembly is in the protocol to be used. Is it a good idea, that’s another question. Is it practical, that is another question.

> You say that "it is off by default" -- but I don't see that in this document (nor, at a quick glance, in RFC 7832 - "Locator/ID Separation Protocol (LISP) Threat Analysis”).

It has been implemented in products as off by default.

> Um, I don't think this is right (or I've misunderstood) - you don't store "the last nonce that came with the E-bit set" (one number), you have to store "the last nonce that came with the E-bit set for every ITR which is sending them”.

Right. The context was from a single encapsulator.

> These have to be stored somewhere, and this is a limited size space (N slots). If I send you N+1 spoofed packets you will have to evict something from this space -- what am I missing?

They are stored in the map-cache since you encap to that ITR (which is now an ETR). So its a 24-bit number you use in an RLOC data structure in your implemenation. I have implemented this way twice (in 2 different implementations).

> Yes, many implementations default to not setting advertising they are echo-nonce capable in Map-Replies. So RLOC-probing tends to be used for RLOC reachability. Plus we added features into RLOC-pro…

The LISP WG can provide pointes. Damien and Luigi did extensive research on this.

> As someone who was born in Africa and has seen the effects of famine firsthand, I find this statement offensive -- people don't starve to death because they didn't feel like eating their broccoli, they starve to death because there isn't any food.

It wasn’t intended to be offensive. And if that is how it was received, I am sorry for that.

Dino

---

From: Warren Kumari <[email-masked]>
Date: Wed, 6 Feb 2019 16:38:59 -0500

On Wed, Feb 6, 2019 at 2:41 PM Dino Farinacci <[email-masked]> wrote:

> > A better analogy would be Neighbor Discovery, where a random person on
> the Internet can cause your router to have to build state -- and we ended
> up having to publish RFC6583 - "Operational Neighbor Discovery Problems" to
> I don’t think it is. Because a BGP table and a cache is still allocable
> memory that has to be managed. And it doesn’t matter if peers are
> configured or not, a bad peer can still damage a BGP cache.
>

Which changed text? It wasn't (as far as I could see) in the diff which you
attacked earlier.
Also, in the diff there is still the "example" typo: "For exmple of such
attacks"

> > We have chosen 3 methods to deal with MTU issues because ETR reassembly
> is the worst approach. And I certainly wouldn’t recommend using it.
> >
> I don’t think it should. If someone has ETR resources to do so, it should
> be able to do it. Fragmentation/assembly is in the protocol to be used. Is
> it a good idea, that’s another question. Is it practical, that is another
> question.
>
> > It was a Google employee in the early days that wanted this feature
> (circa 2007). ;-) It was so return packets from a server side didn’t have
> to do the mapping system lookup. It is off by default and only used in
> trusted enviornments where you can control how the ITR and ETR behave.
> >
> Protocol (LISP) Threat Analysis”).
>

... and someone reading this document is supposed to know that how? The
purpose of publishing documents like this is to allow for interoperable
implementations - expecting implementers to have to examine other
implementations to learn how not to shoot themselves in the foot doesn't
help anyone.

> > Um, I don't think this is right (or I've misunderstood) - you don't
> store "the last nonce that came with the E-bit set" (one number), you have
> to store "the last nonce that came with the E-bit set for every ITR which
> is sending them”.
>
> They are stored in the map-cache since you encap to that ITR (which is now
> an ETR). So its a 24-bit number you use in an RLOC data structure in your
> implemenation. I have implemented this way twice (in 2 different
> implementations).
>

Ok, this seems seems like a good optimization (but does require that the
RLOC storage needs to be larger ) - why not suggest this in the document?
It would only take a sentence or two, and would make future implementations
more likely / resilient.

> The LISP WG can provide pointes. Damien and Luigi did extensive research
Again, something like "many implementations default to not advertising that
they are echo-nonce capable in Map-Replies and so RLOC-probing tends to be
used for RLOC reachability." would help - there is no harm in trying to
make things easier for your readers / future implementors.

> > An ETR can verify mappings if it chooses to. The more overhead you want
> to put in the system for anti-spoofing, one can do. Tradeoffs.
> >
Ok. No worries.
W

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 6 Feb 2019 14:07:04 -0800

> Which changed text? It wasn't (as far as I could see) in the diff which you attacked earlier. 
> Also, in the diff there is still the "example" typo: "For exmple of such attacks”

I was referring to the MTU text. We combined two discussion points at the same time. I was referring to the the size of the packet that the ITR needs to encapsulate and that L includes the size of the encapsulation headers.

Fixed the typo.

> ... and someone reading this document is supposed to know that how? The purpose of publishing documents like this is to allow for interoperable implementations - expecting implementers to have to examine other implementations to learn how not to shoot themselves in the foot doesn't help anyone. 

Tell me why this text does not satisfy your concern?

It’s at the end of section 9.

> Ok, this seems seems like a good optimization (but does require that the RLOC storage needs to be larger ) - why not suggest this in the document? It would only take a sentence or two, and would make future implementations more likely / resilient. 

Because we have decided that many things like this be left for implementor creativity and experimentation.

> Again, something like "many implementations default to not advertising that they are echo-nonce capable in Map-Replies and so RLOC-probing tends to be used for RLOC reachability." would help - there is no harm in trying to make things easier for your readers / future implementors.

I have added your text. See new diff enclosed.

Dino