Subject: Re: [lisp] #8: Limits on "Gleaned" Map Entries Not Clear

From: [email-masked] (Noel Chiappa)
Date: Wed, 9 Sep 2009 00:00:29 -0400 (EDT)

> From: Margaret Wasserman <[email-masked]>

    >> That cannot happen. I think you may be convince of that now?

    > No, I don't see what would stop this from happening...
    > ...
    > (1) The attacker manages to send a spoofed map reply that gets
    > processed by the ITR.
    > ...
    > We all seem to agree that this can happen "for a few seconds" if an
    > attacker sends a packet that will generate an incorrect "gleaned" entry.

My brain isn't working too crisply today, but on thinking about it a bit, I
think I may have seen what Dino was getting at. It has to do with your point
(1), and the "if an attacker [can] send a packet that will generate an
incorrect 'gleaned' entry" - because that last may be harder than it seems.

Start with a point you made a couple of messages back:

    >>> a "gleaned" map-cache entry will not be created if a map entry
    >>> already exists for an EID prefix containing the EID in the received
    >>> packet

In other words, the gleaning attack can't even _start_ iff a cached map entry
_already exists_. Put another way, it's only possible to attack mappings
which aren't _already_ cached in the ITR. Any bogus packets, with a bad
mapping, will be ignored if a valid cache entry for that EID already exists.

So there are only two possible 'windows' in which one could do the two-step
attack. (Step one, 'glean' a bad mapping; step two, validate the bad mapping
by pre-empting the lookup by flooding the target with bogus replies. Actually,
there might be circumstances in which one can go directly to the second step;
see below.)

The first potential 'window' is before a mapping to a particular destination
exists; but for popular destinations, there's probably only a small time
period when that is true, shortly after an ITR restarts. If an attacker can
cause an ITR to crash and restart, then perhaps this attack would be mounted,
but that does make the attack harder.

For non-popular destinations, the attacker would have to know that a user was
about to attempt communication with a given destination (because installing a
bogus mapping for a destination that nobody at the attacked site was going to
communicate with would be a waste of time), which again sounds like it might
be fairly tricky.

The second potential 'window' is just after a cached mapping times out. I
don't recall exactly how timed-out map entries are handled, but if such
entries become 'provisional', and a validate cycle is started, then the
attacker could try the second step (only) of the two-step attack - but they
would have to know when the entry times out, and I don't see how they could
know that.

None of which should be construed as an opinion one way or the other on
whether it's worth making it harder to spoof Map-Replies - just trying to
explain why the hole may be very hard to exploit, in practise.

	Noel

---

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

But you know Noel, all this is not really needed. I mean the data  
gleaning provides little value in an untrusted environment.

If the ITR is going to send a verifying Map-Request, it could just  
sent a regular one for a return packet. The reason we put data  
gleaning in the spec is because we talked to hosting providers that  
wanted to reduce the additional delay in returning packets to client  
sites.

So if they send any type of Map-Request, being it verifying or a  
regular one, it adds delay. Therefore, the feature can only be used in  
a trusted environment. We have heard from enterprise sites who want to  
run LISP internally to their branch offices, would use this feature  
*without* the verifying step.

But I would say for the capital-I Internet, this may not be a useful  
feature. So we should limit our time working on it.

Dino

On Sep 8, 2009, at 9:00 PM, Noel Chiappa wrote:

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Sep 2009 07:39:51 -0400

Hi.

Last night, I was trying to convince Margaret that the 32-bit nonce in
the map request was sufficient to protect against her attack, but in
the process of trying to do so, convinced myself that her attack is
too plausible for my comfort.

I'm an attacker trying to attack ITR A.

1) Find some EID B that if A looks up a mapping entry for B, it won't
get a response.  For example, someone who is still registered with
their map server, but for whom there is some routing problem between
B's ETR and A.  Or go attack B and create a routing problem so that
B's ETR's packets don't get to A.

2) Send A traffic that will cause A to look up the mapping for B.
Often, spoofing traffic that appears to be sourced from B is
sufficient for this.  There may also be LISP mechanisms sufficient to
get this to happen.

3) Generate a bunch of fake map replies, each with a different nonce.
If you happen to guess the nonce that A used, then you can insert a
verified mapping entry with a fairly large TTL.

So, how likely is it?  Well, let's assume a gig link, so roughly 2^30
bits/second.  Let's assume my map reply packets are roughly 2^12 bits.
So, I can send around 2^18 packets a second if I don't mind flooding
your link. That gives me a probability of success in a second of 1 in
2^14.  However I can repeat the attack.  I have a very good
probability of success if I'm willing to spend 2^14 seconds or about 4
hours.

Now, probably it doesn't quite work that way.  I suspect I may be off
by as much as a factor of 4 in terms of how much overhead is involved,
and how much I can stuff on a gig link.  Also, if I generate a gig of
traffic at someone for four hours, I'm going to fail on the subtle
front.  I'm also unconvinced that even if it could handle the load,
any sane control plane would accept that much traffic from one
source.  However, I can scale back and say spend 10 days rather than
four hours.

Yes, I can think of cases where this attack seems practical and where
spending a few days to get a mapping cache entry is worth it.

My conclusion here is that 32-bits is not a big enough nonce in the
map request and reply.  I think that for the price of four bytes per
packet,and a 64-bit nonce, we could completely solve this particular
attack.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Sep 2009 08:40:40 -0400

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:

    Dino> But you know Noel, all this is not really needed. I mean the
    Dino> data gleaning provides little value in an untrusted
    Dino> environment.

    Dino> If the ITR is going to send a verifying Map-Request, it
    Dino> could just sent a regular one for a return packet. The
    Dino> reason we put data gleaning in the spec is because we talked
    Dino> to hosting providers that wanted to reduce the additional
    Dino> delay in returning packets to client sites.

    Dino> So if they send any type of Map-Request, being it verifying
    Dino> or a regular one, it adds delay. Therefore, the feature can
    Dino> only be used in a trusted environment. We have heard from
    Dino> enterprise sites who want to run LISP internally to their
    Dino> branch offices, would use this feature *without* the
    Dino> verifying step.

    Dino> But I would say for the capital-I Internet, this may not be
    Dino> a useful feature. So we should limit our time working on it.

Then let's remove it.  We're chartered to design LISP for the Internet
to solve the Internet route scaling problem.  I agree with you that it
is not useful in the Internet environment, but it significantly
complicates the security analysis and once we actually have a security
model we'll probably end up removing it then.

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Wed, 9 Sep 2009 09:06:40 -0700

> B's ETR's packets don't get to A.

A routing problem on the ALT? But basically the map-request is dropped.

> sufficient for this.  There may also be LISP mechanisms sufficient to

Yes this is possible.

> verified mapping entry with a fairly large TTL.

A bunch, as in several thousand?  Remember these map replies will be
rate limited, and the fact that they have incorrect nonce's logged.

> probability of success if I'm willing to spend 2^14 seconds or about 4

The key isn't the access link speed, it's the capacity of the control
plane of the ITR and the rate limiting mechanisms into the control
plane.  This will result in a _few hundred_ packets per second of
map-replies being the maximum allowed by the implementation.  So I
suspect you're off by several orders of magnitude in your timing because
of this.

> source.  However, I can scale back and say spend 10 days rather than

If you notice you're under attack, you (if possible) access list this
attacker, and if you cannot you call your upstream provider, traceback
the attack with the help of your upstream, possibly black hole the
source, change the IP of your link, etc.  Basically all the ways you
deal with an attack today.  

> spending a few days to get a mapping cache entry is worth it.

I'm sorry I disagree with you.  

> packet,and a 64-bit nonce, we could completely solve this particular

I disagree with your conclusion, I feel this is not a feasible attack,
and you haven't shown it to be operationally practical.

-Darrel

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Sep 2009 12:17:19 -0400

>>>>> "Darrel" == Darrel Lewis (darlewis) <[email-masked]> writes:

    >> 1) Find some EID B that if A looks up a mapping entry for B, it
    >> won't get a response.  For example, someone who is still
    >> registered with their map server, but for whom there is some
    >> routing problem between B's ETR and A.  Or go attack B and
    >> create a routing problem so that B's ETR's packets don't get to
    >> A.

    Darrel> A routing problem on the ALT? But basically the
    Darrel> map-request is dropped.
No, a routing problem between the ETR serving B and A.
Being able to suppress the map request from getting to B's ETR is nice but not required.

    Darrel> replies will be rate limited, and the fact that they have
    Darrel> incorrect nonce's logged.

    Darrel> The key isn't the access link speed, it's the capacity of
    Darrel> the control plane of the ITR and the rate limiting
    Darrel> mechanisms into the control plane.  This will result in a
    Darrel> _few hundred_ packets per second of map-replies being the
    Darrel> maximum allowed by the implementation.  So I suspect
    Darrel> you're off by several orders of magnitude in your timing
    Darrel> because of this.
OK, so we're talking a month to mount the attack.  Sorry, but that is
still outside my comfort margins given the simplicity of the fix.

Again, I don't think it is reasonable to require sites to notice
attacks like this and to take steps to stop them--possibly having to
root out an entire distributed botnet--when we can fix the problem
with a reasonably small protocol change.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 9 Sep 2009 14:16:04 -0400

Hi Darrel,

> rate limited, and the fact that they have incorrect nonce's logged.

In the attack we are describing, "these map replies" are being sent by  
an attacker (possibly from multiple remote ETRs) to insert a spoofed  
map-cache entry in an ITR.  I realize that the LISP spec says that the  
sender should rate limit its replies, but attackers don't typically  
follow that sort of advice.

Margaret

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Wed, 9 Sep 2009 12:18:46 -0700

> follow that sort of advice.

These map replies are rate limited by the receiving ITR, either
specifically by LISP, or more genreally by such mechanisms as Control
Plane Policing, not by the attacker. I'm not relying or expecting on the
attacker following the specification's behavior.

-Darrel

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 9 Sep 2009 16:37:20 -0400

> attacker following the specification's behavior.

As I mentioned in private mail...  If the security of LISP depends on  
ITRs doing this sort of rate limiting, we should make sure to mention  
this in the security considerations section.

Personally, though, I think that it would be better to just increase  
the nonce size to 64-bits.  Then we will quickly go from quibbling  
about whether it takes days, weeks or months to break the nonce-based  
security to all agreeing that it would take longer than the expected  
market lifetime of silicon-based chips...  I really don't see that  
using a 64-bit nonce in control-plane packets has any significant cost.

Margaret

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Wed, 9 Sep 2009 14:32:03 -0700

he specification's behavior.
> this in the security considerations section.

Margaret, the security considerations section in draft-ietf-lisp-03
says, in part:

   DoS attack prevention will depend on implementations rate-limiting
   Map-Requests and Map-Replies to the control plane as well as rate-
   limiting the number of data-triggered Map-Replies.

Do you think this is sufficient?  If not, can you propose further text?

-Darrel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 09 Sep 2009 17:46:01 -0400

At the very least, I would think it needs to indicate that rate limiting 
should apply to both the generation and the processing of such messages.

Yours,
Joel

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 9 Sep 2009 20:00:44 -0400

Hi Darrel,

>   limiting the number of data-triggered Map-Replies.

I thought that this text was talking about implementations rate  
limiting what they transmit, but I now see that it says "to the  
control plane".  I'm not sure if there is a clearer way to say this  
that would have avoided my misunderstanding...  Maybe "The prevention  
of DoS and map-cache spoofing attacks will depend on implementations  
rate limiting the number of control packets that are received and  
processed by their data plane."?

I am also not sure what "data-triggered Map-Replies" are.  Did you  
mean "data-triggered Map-Requests"?

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 9 Sep 2009 20:20:22 -0400

On Sep 9, 2009, at 8:00 PM, Margaret Wasserman wrote:
> that would have avoided my misunderstanding...  Maybe "The  
> prevention of DoS and map-cache spoofing attacks will depend on  
> implementations rate limiting the number of control packets that are  
> received and processed by their data plane."?

s/data plane./control plane.

Margaret

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 9 Sep 2009 23:33:38 -0400

On Wed, Sep 9, 2009 at 4:37 PM, Margaret Wasserman<[email-masked]> wrote:
> As I mentioned in private mail...  If the security of LISP depends on ITRs
> doing this sort of rate limiting, we should make sure to mention this in the
> security considerations section.

also, please, please, please mention that making the nonce a
sequential number isn't a good plan, nor is using a prng of poor
quality. Let's not incur the same sets of issues TCP has had with
seq#.

> Personally, though, I think that it would be better to just increase the
> nonce size to 64-bits.  Then we will quickly go from quibbling about whether
> it takes days, weeks or months to break the nonce-based security to all
> agreeing that it would take longer than the expected market lifetime of
> silicon-based chips...  I really don't see that using a 64-bit nonce in

provided that my above note is also adhered to, if you just seq+1 to
get the next nonce to use... your bit numbers are meaningless :(

> control-plane packets has any significant cost.

It does cost in header space, right? and potentially this cost is also
in chips/hardware that may have to look more bits into a header to
make a decision, though I believe the NONCE is more targetted to the
RP/RE/smarts of a router than the line-card/forwarding-parts, right?

-chris

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 9 Sep 2009 23:38:37 -0400

> quality. Let's not incur the same sets of issues TCP has had with

Yes, we need to say something about using a good source of random  
numbers.  I think there is an RFC we can reference with advice about  
that, but I'll have to look up the number tomorrow.
> get the next nonce to use... your bit numbers are meaningless :(

True.
> RP/RE/smarts of a router than the line-card/forwarding-parts, right?

Yes, we are only talking about the nonce in the control-plane packets  
-- map registration, map request, map reply, etc.  The LISP data  
header currently has a 24-bit nonce, but that nonce is not the subject  
of this discussion.  Increasing the size of the data header could have  
significant impact along the lines you mention, but increasing the  
size of the control messages should not (IMO) cause any serious issues.

Margaret

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 9 Sep 2009 23:41:58 -0400

On Wed, Sep 9, 2009 at 11:38 PM, Margaret Wasserman<[email-masked]> wrote:
> Yes, we need to say something about using a good source of random numbers.
>  I think there is an RFC we can reference with advice about that, but I'll
> have to look up the number tomorrow.

ok, cool.. perhaps it's ne related to TCP even :)

>> get the next nonce to use... your bit numbers are meaningless :(

I also forgot to say that... given the box will likely fall over
before you hit even a 2^32 number of packets I'm not sure there's a
win in 2^64. Especially if the nonce isn't very long-lived, the time
to stay under the rate-limit threshold (hitting it will have other
mal-effects), will be compressed so 2^32 really is quite a few packets
in this context.

> Yes, we are only talking about the nonce in the control-plane packets -- map

great, thanks.

-chris

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Wed, 9 Sep 2009 21:26:11 -0700

> should apply to both the generation and the processing of 

Thanks Joel, I'll add the language you suggest. I don't want to be too
specific because such recommendations are very dependant on the device
capabilities how exactly LISP is implemented. 

-Darrel

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 9 Sep 2009 23:53:30 -0700

> that, but I'll have to look up the number tomorrow.

Chris, how about I add this text to the spec:

    Nonce:  An 8-byte random value created by the sender of the Map-
       Request.  This nonce will be returned in the Map-Reply.  A
       suggested source for good random number generation can be found  
in
       [RFC1750].

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Sep 2009 08:57:02 -0400

I would suggest RFC 4086 (which obsoleted 1750).
Joel

Dino Farinacci wrote:
>       suggested source for good random number generation can be found in
>       [RFC1750].
> 
> Dino
>

---

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

> that, but I'll have to look up the number tomorrow.

The document I mentioned is RFC 4086:  Randomness Requirements for  
Security.  Since the LISP nonce (in the control packets, anyway) is a  
security nonce, I think we should state that the nonce should be  
generated using a source of random numbers that meets the requirements  
in RFC 4086.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 10 Sep 2009 10:21:43 -0400

>      suggested source for good random number generation can be found  

That isn't the right RFC.  You should cite RFC 4086.

Also, because this is s security-sensitive nonce, I think that we  
should state that "the nonce MUST be generated using a source of  
random numbers that meets the requirements in RFC 4086", not just  
suggest that implementations use a good random number generator.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 10 Sep 2009 10:25:07 -0400

On Thu, Sep 10, 2009 at 9:58 AM, Margaret Wasserman<[email-masked]> wrote:
> The document I mentioned is RFC 4086:  Randomness Requirements for Security.
>  Since the LISP nonce (in the control packets, anyway) is a security nonce,
> I think we should state that the nonce should be generated using a source of
> random numbers that meets the requirements in RFC 4086.

yes please.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 10 Sep 2009 10:26:23 -0400

On Thu, Sep 10, 2009 at 10:21 AM, Margaret Wasserman<[email-masked]> wrote:
> Also, because this is s security-sensitive nonce, I think that we should
> state that "the nonce MUST be generated using a source of random numbers
> that meets the requirements in RFC 4086", not just suggest that
> implementations use a good random number generator.

Dino, yup just switching the rfc reference as margaret noted seems good to me.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 10 Sep 2009 09:30:47 -0700

> suggest that implementations use a good random number generator.

How about SHOULD instead of MUST?

Dino

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Sep 2009 12:50:57 -0400

>>>>> "Margaret" == Margaret Wasserman <[email-masked]> writes:

    Margaret> On Sep 10, 2009, at 2:53 AM, Dino Farinacci wrote:
    >> in [RFC1750].

    Margaret> That isn't the right RFC.  You should cite RFC 4086.

    Margaret> Also, because this is s security-sensitive nonce, I
    Margaret> think that we should state that "the nonce MUST be
    Margaret> generated using a source of random numbers that meets
    Margaret> the requirements in RFC 4086", not just suggest that
    Margaret> implementations use a good random number
    Margaret> generator

Hmm.  I didn't think 4086 gave requirements so much as advice.
>From the latest IPsec specs we have
   The security of this protocol is critically dependent on the
   randomness of the randomly chosen parameters.  These should be
   generated by a strong random or properly seeded pseudo-random source
   (see [RFC4086]).  Implementers should take care to ensure that use of
   random numbers for both keys and nonces is engineered in a fashion
   that does not undermine the security of the keys.

I'd do something like.

The security of the LISP mapping protocol depends critically on the
strength of the nonce in the map request and reply messages.  These
nonces MUST be generated by a properly seeded pseudo-random (or strong
random) source.  See RFC 4086 for advice on generating
security-sensitive random data.

I think LISP wants a pseudo-random source because a strong random
source is with current hardware going to be highly impractical from a
performance standpoint.  RFC 4086 should be a normative reference.

---

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

> How about SHOULD instead of MUST?

That works for me.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 10 Sep 2009 12:56:43 -0400

> security-sensitive random data.

This wording would be fine with me.  I'd also be find with the "MUST"  
in the above wording being changed to a "SHOULD".

The important points, to me, are that we stress that this is a  
security-sensitive nonce, and that the security of the system depends  
on good random number generation (a la RFC 4086).

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Sep 2009 13:00:52 -0400

Margaret> On Sep 10, 2009, at 12:50 PM, Sam Hartman wrote:
    >> The security of the LISP mapping protocol depends critically on
    >> the strength of the nonce in the map request and reply
    >> messages.  These nonces MUST be generated by a properly seeded
    >> pseudo-random (or strong random) source.  See RFC 4086 for
    >> advice on generating security-sensitive random data.

    Margaret> This wording would be fine with me.  I'd also be find
    Margaret> with the "MUST" in the above wording being changed to a
    Margaret> "SHOULD".

I'd prefer MUST, but I could live with SHOULD.  I was quoting from a
source that used lower case should to state fairly strong
requirements, and in the translation musted because I thought that was
consistent with the original intent.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Sep 2009 19:20:56 +0200

> performance standpoint.  RFC 4086 should be a normative reference.

This seems like good text, Sam.  It's amazing how many times
implementations get that stuff wrong (and it's so easy to get wrong).

Eliot

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 10 Sep 2009 22:22:45 -0700

I will include Sam's text with a SHOULD. Since the attack is going to  
be rare with a 64-bit guess, any random number generator will be  
fairly good IMO. But we can suggest the RFC 4086.

I'll update the diffs with this text. Thanks all.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 10 Sep 2009 22:34:37 -0700

By the way, I change the text a bit because a Map-Reply doesn't have a  
"nonce generation" but echos the nonce from the Map-Request. So this  
is what I'd include:

    Nonce:  An 8-byte random value created by the sender of the Map-
       Request.  This nonce will be returned in the Map-Reply.  The
       security of the LISP mapping protocol depends critically on the
       strength of the nonce in the Map-Request message.  The nonce
       SHOULD be generated by a properly seeded pseudo-random (or strong
       random) source.  See [RFC4086] for advice on generating security-
       sensitive random data.

Okay?

Dino

On Sep 10, 2009, at 10:22 PM, Dino Farinacci wrote:

> I will include Sam's text with a SHOULD. Since the attack is going  
> to be rare with a 64-bit guess, any random number generator will be

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 11 Sep 2009 07:47:25 -0400

> fairly good IMO. But we can suggest the RFC 4086.

If you are going to use a should, I would provide more advice for the  
non-compliant - how about adding :

>>> random) source.

Nonces MUST NOT be generated by easy to guess methods such as a simple  
sequence number or system time code.

>>> See RFC 4086 for advice on generating

I agree with that. My understanding is that on some systems the supply  
of truly random bits is pretty limited.

Also, can someone tell me why "pre-play" attacks are not an issue ?   
(See Sections 4 and 10 of draft-ietf-manet-smf-09; Section 6.4 of RFC  
4418 discusses measures against the more familiar replay attacks.) In  
this context, a pre-play attack would be a response from an attacker  
to a Map-request that arrives before the true response from the EID.

If I am running a multi-mega-node botnet, why shouldn't I have my bots  
listen for passing traffic, find any LISP Map Requests, and respond  
immediately, thereby possibly preempting the true EID and if so  
allowing for the same sorts of mischief as in Sam and Margaret's nonce  
guessing attack ? This would work any time my bots were on a large  
flat LAN or on a wireless network with either the EID or the ITR.  
Particularly if my bot was on the network with the ITR, the false  
response (with the correct nonce) could easily arrive before the true  
one. As UDP is unreliable, my response might even be the only one that  
arrived. I could probably also spoof the EID IP address and adjust  
TTLs to mimic the true response.

It seems to me that this could be detected easily (the ITR starts a  
timer with a window at the sending of each Map-request, listens for  
duplicate but disagreeing Mao-replies during the duration of the  
window) but mere rejection of duplicate Nonce responses would allow  
for an easy LISP DOS (as the good Map-reply would be thrown out with  
the bad).

I don't see any way to stop this without a shared secret. If there is  
a shared secret, then the treatment of the Nonce should probably be  
changed (ITR sends the Nonce, EID replies with the Nonce hashed  
together with the shared secret).

Regards
Marshall

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 11 Sep 2009 09:10:43 -0700

I would prefer to keep the text the way it is Marshall. We have  
addressed Chris' comment which was to not use a dumb or predictable  
random number generator, like a sequential allocator or a non-granular  
data-stamp.

I would like to leave it to the implementors to decide what type of  
random number generator to use. But having a  suggested reference is  
good for implementators to evaluate.

Dino

On Sep 11, 2009, at 4:47 AM, Marshall Eubanks wrote:

> If you are going to use a should, I would provide more advice for  
> the non-compliant - how about adding :
>
>>
> Nonces MUST NOT be generated by easy to guess methods such as a  
> simple sequence number or system time code.
>
> I agree with that. My understanding is that on some systems the  
> supply of truly random bits is pretty limited.
>
> (See Sections 4 and 10 of draft-ietf-manet-smf-09; Section 6.4 of  
> RFC 4418 discusses measures against the more familiar replay  
> attacks.) In this context, a pre-play attack would be a response  
> from an attacker to a Map-request that arrives before the true  
> response from the EID.
>
> If I am running a multi-mega-node botnet, why shouldn't I have my  
> bots listen for passing traffic, find any LISP Map Requests, and  
> respond immediately, thereby possibly preempting the true EID and if  
> so allowing for the same sorts of mischief as in Sam and Margaret's  
> nonce guessing attack ? This would work any time my bots were on a  
> large flat LAN or on a wireless network with either the EID or the  
> ITR. Particularly if my bot was on the network with the ITR, the  
> false response (with the correct nonce) could easily arrive before  
> the true one. As UDP is unreliable, my response might even be the  
> only one that arrived. I could probably also spoof the EID IP  
> address and adjust TTLs to mimic the true response.
>
> I don't see any way to stop this without a shared secret. If there  
> is a shared secret, then the treatment of the Nonce should probably  
> be changed (ITR sends the Nonce, EID replies with the Nonce hashed