Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

From: [email-masked] (Noel Chiappa)
Date: Tue, 19 Jul 2011 16:25:25 -0400 (EDT)

> From: Jeff Wheeler <[email-masked]>

    > cache eviction is also a problem here. The traffic from host1 could still
    > cause enough churn in the ITR that all mappings might be evicted from the
    > FIB, which would then cause all hosts to appear to be churning even
    > though they are sending only routine traffic.

Hence my suggestion for partitioning the cache, to limit the part being
thrashed. The thing is that partitioning the cache to prevent the entire cache
being thrashed is a general strategy, which can be applied in all sorts of ways
(see below).

Note that 'partitioning the cache' is not the same as 'having separate caches'
for each <whatever>. The contents of the entire cache is still availble for all
users, so that if client machine A causes the mapping for large content
provider P to be cached, clients machines B, C, etc can all use that mapping.
It's only partitioned so that attempts to thrash it only thrash a section of
it, causing only some degradation of service, not denial.

    > One might say, don't evict a "busy" cache entry to install a mapping for
    > only one packet if the cache is currently full, but it is not safe to
    > assume that an attack would not simply send several packets

One can easily imagine all sorts of ways to partition the cache, other than the
one I suggested (which was to separate out highly-used mappings from new ones),
if that proves to be not good enough. E.g. one could _also_ have code so that
no individual client machine (i.e. source) can be the source of more than N% of
the mappings, so that when a 'request' for the N+1th mapping arrives from that
source, one of its oldest/least-used mappings gets evicted. Etc, etc, etc.

It has been suggested that this might be a value-added differentiator for
vendors, in fact - whose cache is most resistant to DoS?

    > (in fact, TCP stack on host1 would do this normally, in the case of a
    > reflection attack where it is sending SYN|ACK several times.)

If that machine is a server, it probably out to be tweaked to not retransmit
SYN-ACKs - if it's a legit connection, let the other end retransmit.

	Noel

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 20 Jul 2011 12:07:53 -0400

> vendors, in fact - whose cache is most resistant to DoS?

Noel,

At the risk of repeating myself, I think that the cache partitioning strategy should be spelled out in the specification. If we specify it, the strategy will benefit from wide review.

If we don't specify a strategy, the specification should at least point out that there is a sharp edge here, and that no strategy has been demonstrated to address all corner cases.

                                                             Ron

---

From: Jeff Wheeler <[email-masked]>
Date: Wed, 20 Jul 2011 12:52:28 -0400

> If we don't specify a strategy, the specification should at least point out that there is a sharp edge here, and that no strategy has been demonstrated to address all corner cases.

I favor your second suggestion.  I do not think the specification
should dictate how the cache is managed.  Vendors should feel free to
innovate in this area.  I agree with Noel that some vendors will do a
better job than others, and may even present the operator with
configurable choices.  Cisco is doing this in the area of ND Cache,
which is a remarkably similar problem.

The change I think is necessary is to make the MS protocol more
flexible.  The negative response problem I pointed out to start this
discussion can be substantially improved by vendor implementations if
the MS is able to reply with an aggregate negative mapping as well as
one or more positive mappings (more-specifics.)  I also still believe
that operators may demand xTRs be able to carry all mappings in some
situations, and the MS protocol should be capable of supplying that
data.  This permits vendors to build boxes with that feature, and
large enough FIB, if they believe customers will buy them.

--
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 20 Jul 2011 13:56:29 -0400

Let me suggest a different phrasing Ron...
It would seem reasonable to include discussion of this issue in a 
document.  However, I do not see that it needs to be in the base specs 
at this stage of the game.  A separate additional work item, if we have 
folks willing and interested in doing so, seems sensible.

Yours,
Joel

On 7/20/2011 12:07 PM, Ronald Bonica wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 20 Jul 2011 14:45:53 -0400

Joel,

I am fine with Jeff's proposal. We can simply note that "there is a sharp edge here, and that no strategy has
been demonstrated to address all corner cases." When the issue has been adequately addressed, we can issue a bis document that does not include the caveat.

                                                 Ron

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Wednesday, July 20, 2011 1:56 PM
> To: Ronald Bonica
> Cc: Noel Chiappa; [email-masked]; [email-masked]
> Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why
> is IPv6 broken?)
> 
> >> One can easily imagine all sorts of ways to partition the cache,
> other
> >> than the
> >> if that proves to be not good enough. E.g. one could _also_ have
> code
> >> so that
> >> source, one of its oldest/least-used mappings gets evicted. Etc,
> etc,
> >> etc.
> >>
> >> It has been suggested that this might be a value-added
> differentiator
> >> for
> > At the risk of repeating myself, I think that the cache partitioning
> strategy should be spelled out in the specification. If we specify it,
> the strategy will benefit from wide review.
> >
> > If we don't specify a strategy, the specification should at least
> point out that there is a sharp edge here, and that no strategy has
> been demonstrated to address all corner cases.
> >
> >                                                               Ron
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 20 Jul 2011 15:01:35 -0400

There already is warning text on this in the document.
If we are going to add yet more warning to the documents we are 
currently working on, I would want to see specific proposed text with a 
specific placement.

Thank you,
Joel

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 20 Jul 2011 16:00:26 -0400

I will generate some text late this week.

                                Ron

> Sent: Wednesday, July 20, 2011 3:02 PM
> To: Ronald Bonica
> > I am fine with Jeff's proposal. We can simply note that "there is a
> sharp edge here, and that no strategy has
> > been demonstrated to address all corner cases." When the issue has
> been adequately addressed, we can issue a bis document that does not
> include the caveat.
> >
> >                                                   Ron
> >
> >
> >>>> one I suggested (which was to separate out highly-used mappings
> from
> >>>> new ones),
> >>>> no individual client machine (i.e. source) can be the source of
> more
> >>>> than N% of
> >>>> the mappings, so that when a 'request' for the N+1th mapping
> arrives
> >>>> from that

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 20 Jul 2011 14:51:16 -0700

Jeff,

I would be interested in your assessment of whether
this caching issue applies also to IRON [RFC6179].
I think it probably doesn't, because the IRON tunnel
endpoints are not trying to hold all recently heard
from correspondents in their cache, but I would be
interested to hear what you think.

Thanks - Fred

---

From: Jeff Wheeler <[email-masked]>
Date: Wed, 20 Jul 2011 19:26:33 -0400

> this caching issue applies also to IRON [RFC6179].

I am not familiar with this work, and have only had a chance to skim
RFC6179.  However, it appears to me that IRON does not direct the IRON
routers specifically to employ a cache, and indeed within each VPC,
the routing protocol used to manage the VP may be different from
others.  So unlike LISP, which essentially requires the use of
cache-based FIB and the LISP MS protocol for routing state, a VPC
could choose to implement whatever they decide is smart for their own
application, or purchase equipment from a vendor who has implemented
what they feel is adequate.

> interested to hear what you think.

The problems I have been discussing with LISP are not related to
payload buffering, but to routing state.

One thing that jumps out at me about IRON, and keep in mind I have
only skimmed the RFC and I may be incorrect, but I believe that,
within a given VPC, malicious host H might send encapsulated packets
to server A, when in fact server C is responsible for routing for
those packets' destination EP.  I believe IRON specifies that server A
would do two things in this scenario; 1) forward the packet to server
C, and 2) send a redirect back to the Locator address in the
outer-header (probably not host H's address, but a forged/spoofed
address.)  This would allow the use of server A for reflecting an
attack against server C, and also, some other Locator would receive
redirect messages at whatever rate they are generated.  This seems
less than ideal.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 21 Jul 2011 08:48:07 -0700

Hi Jeff, 

> From: Jeff Wheeler [mailto:[email-masked]] 
> Sent: Wednesday, July 20, 2011 4:27 PM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [lisp] Fwd: Anybody can participate in the IETF 
> (Was: Why is IPv6 broken?)
> 

That is right. IRON is a hybrid routing/mapping
system where standard Internet routing is used
outside of the VPC overlay network, and a
combination of routing/mapping is used inside
of the VPC overlay network. Standard Internet
routing is used between the VPC's relays and
servers, and mappings show up in a client's FIB
based on Redirects received from a trusted Server.
If the mapping cache overflows, a more-specific
route may be lost and a default route will be used
instead. But, there will always be a useable route.

> redirect messages at whatever rate they are generated.  This seems

I think you are right based on what is actually
written in RFC6179, but my understanding of the
model has advanced since that document was written
to where I now believe that there must be strong
authentication between the client and server so
that the server can't be manipulated into causing
an anonymous reflection attack. I have written
about the client/server authentication in
'draft-templin-ironmike'. The redirection
scenario you are describing also won't happen in
the new model I have in mind.

I think what would clear this and other things up
is an RFC6179(bis), which is on my todo list to
initiate.

Thanks - Fred
[email-masked]

---

From: Jeff Wheeler <[email-masked]>
Date: Thu, 21 Jul 2011 13:00:56 -0400

On Thu, Jul 21, 2011 at 11:48 AM, Templin, Fred L <[email-masked]
> wrote:

Is it possible to do this without requiring the data-plane to have
computationally expensive encryption capabilities?  A shared-secret plus
outer-header CRC could probably accomplish this without a big leap from what
is done for forwarding ordinary IP traffic.  This is not cryptographically
strong like more expensive hashes or RSA, but would not limit IRON to being
used for lower-throughput applications.  I am sure there are better ideas
out there than to just use a simple CRC, but this is an example I can
imagine which could be made to work without dramatically more complexity or
power/silicon requirements for data-plane.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 21 Jul 2011 10:15:04 -0700

Hi Jeff,

Actually, when using IPsec tunnels between the client and server
is too heavywieght, IRON uses SEAL encapsulation which has a
48-bit nonce that is a shared secret between the tunnel endpoints.
This provides a deterrent against off-path attacks, but cannot protect
against MITM attacks.

I have gone over and over again in my mind as to whether the SEAL
nonce is an adequate protection, and for what use cases. I could
sure use some help in understanding the security implications.

Thanks - Fred

________________________________
From: Jeff Wheeler [mailto:[email-masked]]
Sent: Thursday, July 21, 2011 10:01 AM
To: Templin, Fred L; [email-masked]
Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?)

On Thu, Jul 21, 2011 at 11:48 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Is it possible to do this without requiring the data-plane to have computationally expensive encryption capabilities?  A shared-secret plus outer-header CRC could probably accomplish this without a big leap from what is done for forwarding ordinary IP traffic.  This is not cryptographically strong like more expensive hashes or RSA, but would not limit IRON to being used for lower-throughput applications.  I am sure there are better ideas out there than to just use a simple CRC, but this is an example I can imagine which could be made to work without dramatically more complexity or power/silicon requirements for data-plane.

--
Jeff S Wheeler <[email-masked]<mailto:[email-masked]>>
Sr Network Operator  /  Innovative Network Concepts

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 22 Jul 2011 16:46:58 -0400

Folks,

The following is the text that I promised.

                                 Ron

6.7 Cache Exhaustion

LISP works best when sufficient memory is allocated to the EID-to-RLOC cache. In this case, whenever a new EID-to-RLOC mapping is required, it can be added to the cache without removing another useful mapping in order to make room. Storage requirements for the EID-to-RLOC cache are determined by the data plane. Because data plane behavior is unpredictable, it is very difficult to determine how much memory needs to be allocated to the EID-to-RLOC cache. Therefore, implementations must behave reasonably well during periods of cache exhaustion.

The following are characteristics of a well-behaved implementation:

- minimizes packet loss
- distributes packet loss across flows in a predictable (and possibly) controllable manner
- does not oversubscribe control plane resources

This memo does not specify cache management algorithms to be executed during periods of cache exhaustion. This is left as an exercise for implementers, and a method through which they can differentiate their implementations from one another. At the time of publication, several algorithms have been discussed, but none has been proven to work better than the others under all conditions.

> From: Ronald Bonica
> Sent: Wednesday, July 20, 2011 4:00 PM
> To: 'Joel M. Halpern'
> Subject: RE: [lisp] Fwd: Anybody can participate in the IETF (Was: Why
> is IPv6 broken?)
>