If there is an LNOLO in an RA, and *in the same RA* there is PIO that matches another prefix that the host believes is on the current link, what should the host conclude? So far all have agreed that the PIO should be preferred. The only issue is for me to produce some text to reflect that. :)
So I have a basic question about LNOLO:
Why do we need it?
If the host solicits and the prefix isn't on the link, then the host
probably wants enough information that it can start configuring for the new
link. A "no" answer isn't sufficient. So why not just send that information
and do away with LNOLO?
jak
Jim - > So I have a basic question about LNOLO: > > > Why do we need it? > > If the router can not do a unicast response because of empty token bucket and completeRA is not possible in the multicast RA because of MTU/bandwidth restrictions, a LNOLO becomes useful in such a scenario. If we don't have a LNOLO, a host receiving a non-completeRA multicast message will have to depend on the overlap of PIOs with its CPL to infer link-change. As I mentioned in my earlier email, IMHO, we should not depend on CPL for DNA solution except for backward compatability. > If the host solicits and the prefix isn't on the link, then the host > probably wants enough information that it can start configuring for the new > link. A "no" answer isn't sufficient. So why not just send that information > and do away with LNOLO? > > How will the host know that it has to start configuration if it doesn't know that there has been a link change? It will have to depend on CPL for this. >> If there is an LNOLO in an RA, and *in the same RA* there is PIO >> that matches another prefix that the host believes is on the >> current link, what should the host conclude? >> >> So far all have agreed that the PIO should be preferred. What is the agreement? If there is a discrepancy in the response from the same router - I think its reasonable to assume something is changing in the link - changes in the prefix, number of routers etc. Assuming one implied response is more accurate than another implied response doesn't seem like the way to go? As, Erik suggested, a fall-back mechanism (with possible additional delays) to get an accurate answer seems like the best thing to do, IMHO. thanks, Sathya >> The only >> issue is for me to produce some text to reflect that. :) >>
Sathya,
>>> >So I have a basic question about LNOLO:
>>> >
>>> >
>>> > Why do we need it?
>>> >
>>> >
>
>> If the router can not do a unicast response because of empty token
>> bucket and completeRA is not possible in the multicast RA because of
>> MTU/bandwidth restrictions, a LNOLO becomes useful in such a scenario.
>> If we don't have a LNOLO, a host receiving a non-completeRA multicast
>> message will have to depend on the overlap of PIOs with its CPL to infer
>> link-change. As I mentioned in my earlier email, IMHO, we should not
>> depend on CPL for DNA solution except for backward compatability.
>>
So I think we disagree.
I think that any multicast response should contain the same information that
is sent in a multicast beacon. I don't think the multicast response should
be custom taylored to match the unicast RSs.
There are two reasons for this. One is simplicity. If we make the
information the same, then the host needs only one set of code for dealing
with multicast RAs.
The other is security. Suppose the router is under DoS attack. One attack
mode might be to simply bombard the router with various fake prefixs in the
requested landmark option. Is the router then supposed to send LNOLO
responses for all of them? If the multicast response is to be robust in the
face of DoS attack, it can't depend on anything in the RSs, because those
can be faked to cause the multicast response to ballon.
>>> >If the host solicits and the prefix isn't on the link, then the host
>>> >probably wants enough information that it can start configuring for the
new
>>> >link. A "no" answer isn't sufficient. So why not just send that
information
>>> >and do away with LNOLO?
>>> >
>>> >
>
>> How will the host know that it has to start configuration if it doesn't
>> know that there has been a link change? It will have to depend on CPL
>> for this.
>>
Precisely!
>>>> >>If there is an LNOLO in an RA, and *in the same RA* there is PIO
>>>> >>that matches another prefix that the host believes is on the
>>>> >>current link, what should the host conclude?
>>>> >>
>>>> >>So far all have agreed that the PIO should be preferred.
>>>> >>
>
>> What is the agreement? If there is a discrepancy in the response from
>> the same router - I think its reasonable to assume something is changing
>> in the link - changes in the prefix, number of routers etc. Assuming one
>> implied response is more accurate than another implied response doesn't
>> seem like the way to go? As, Erik suggested, a fall-back mechanism (with
>> possible additional delays) to get an accurate answer seems like the
>> best thing to do, IMHO.
>>
I think we should drop LNOLO.
jak
Jim - >>> So I have a basic question about LNOLO: >>> Why do we need it? >>> >> >> If the router can not do a unicast response because of empty token >> bucket and completeRA is not possible in the multicast RA because of >> MTU/bandwidth restrictions, a LNOLO becomes useful in such a scenario. >> If we don't have a LNOLO, a host receiving a non-completeRA multicast >> message will have to depend on the overlap of PIOs with its CPL to infer >> link-change. As I mentioned in my earlier email, IMHO, we should not >> depend on CPL for DNA solution except for backward compatability. >> > > So I think we disagree. > > No, I don't think so ;-) > I think that any multicast response should contain the same information that > is sent in a multicast beacon. I agree !!! We should recommend that all multicast RA be completeRA message. But, I don't think we can make this a MUST. So the question is, what should the router do if it can not do completeRA for some reason? OK - while trying to respond to your email - I understood that you are right. Requiring the router to respond to all possible 'fake' prefixes provides a bad loophole that doesn't justify the benefits. CPL is a better alternative for this corner case. (I hate it when people keep on proving me wrong ;-( ) >> What is the agreement? If there is a discrepancy in the response from >> the same router - I think its reasonable to assume something is changing >> in the link - changes in the prefix, number of routers etc. Assuming one >> implied response is more accurate than another implied response doesn't >> seem like the way to go? As, Erik suggested, a fall-back mechanism (with >> possible additional delays) to get an accurate answer seems like the >> best thing to do, IMHO. >> > > I think we should drop LNOLO. > > Agreed. This also negate one of my arguments in the unicast vs multicast RA issue. It will be enough for the router to just note down that it received a RS message after the token bucket empties without needing the specifics of the question asked in the RS message. But, this doesn't address the underlying issue in Issue 9. It is still possible to have discrepancies within a RA when changes are happening. Say, a compeleRA message with the landmark in a PIO and a completely new prefix or a completeRA without the landmark prefix but some overlap to current CPL. I think we should consider a slow-but-accurate mechanism as a fall-back when such discrepancies happen. thanks, Sathya
>But, this doesn't address the underlying issue in Issue 9. It is still
>> possible to have discrepancies within a RA when changes are happening.
>> Say, a compeleRA message with the landmark in a PIO and a completely new
>> prefix or a completeRA without the landmark prefix but some overlap to
>> current CPL. I think we should consider a slow-but-accurate mechanism as
>> a fall-back when such discrepancies happen.
>>
I'm not sure I quite understand the issue here.
Are you saying that there is a possibility that the router is configured
with a new set of prefixes after its unicast token bucket has expired and it
is waiting for the multicast timeout to pop? And that the new configuration
invalidates some of the prefixes that might be sent in RSs prior to the
multicast but after the unicast token bucket has expired?
jak
James Kempf wrote: >> But, this doesn't address the underlying issue in Issue 9. It is still >> possible to have discrepancies within a RA when changes are happening. >> Say, a compeleRA message with the landmark in a PIO and a completely new >> prefix or a completeRA without the landmark prefix but some overlap to >> current CPL. I think we should consider a slow-but-accurate mechanism as >> a fall-back when such discrepancies happen. >> > > I'm not sure I quite understand the issue here. > > Are you saying that there is a possibility that the router is configured > with a new set of prefixes after its unicast token bucket has expired and it > is waiting for the multicast timeout to pop? And that the new configuration > invalidates some of the prefixes that might be sent in RSs prior to the > multicast but after the unicast token bucket has expired? > > You seem to be assuming multicast RA messages are sent only if the token bucket has expired? Thats not the case - AFAIK, there may be multicast RA messages transmitted at anytime. Yes - a new configuration will be one reason - a router going down or coming up (coming up can still be considered just as a cofiguration change, I guess) etc., could lead to discrepancies within the RA message. Rare but possible, I think. - Sathya
>>I'm not sure I quite understand the issue here.
>>> >
>>> >Are you saying that there is a possibility that the router is configured
>>> >with a new set of prefixes after its unicast token bucket has expired and
it
>>> >is waiting for the multicast timeout to pop? And that the new
configuration
>>> >invalidates some of the prefixes that might be sent in RSs prior to the
>>> >multicast but after the unicast token bucket has expired?
>>> >
>>> >
>
>> You seem to be assuming multicast RA messages are sent only if the token
>> bucket has expired? Thats not the case - AFAIK, there may be multicast
>> RA messages transmitted at anytime.
>>
No, I'm not assuming that. But I am recommending that if a multicast message
is sent, it is always formatted in the same manner, to simplify processing
on the host.
>> Yes - a new configuration will be one reason - a router going down or
>> coming up (coming up can still be considered just as a cofiguration
>> change, I guess) etc., could lead to discrepancies within the RA
>> message. Rare but possible, I think.
>>
I think we need some kind of algorithm to allow the routers to co-ordinate
their collection of prefix lists. We've been circling this topic for about a
week now. I'll propose something in a separate email.
jak
Brett Pentland wrote: > If there is an LNOLO in an RA, and *in the same RA* there is PIO > that matches another prefix that the host believes is on the > current link, what should the host conclude? This can happen in two different cases. 1. The router is incorrect and produces an inconsistent RA; the same prefix is in a PIO and the LNOLO. 2. The host and router are out of synch (perhaps due to flash renumbering and reassignment) but the RA itself is self-consistent. For #2 I think we need to look into the larger inconsistency picture. For #1 we could declare such an RA as inconsistent and have the host drop it (the same way a host drops an RA as part of the validation rules in RFC 2461) Erik > So far all have agreed that the PIO should be preferred. The only > issue is for me to produce some text to reflect that. :)
James Kempf wrote: > So I have a basic question about LNOLO: > > > Why do we need it? > > If the host solicits and the prefix isn't on the link, then the host > probably wants enough information that it can start configuring for the new > link. A "no" answer isn't sufficient. So why not just send that information > and do away with LNOLO? I think the semantics of "no, AFAIK that landmark prefix isn't on this link" is a useful one, because the host can immediately take it at face value and - immediately discard its old prefixes, default routers - immediately for a new CoA and initiate MIP type signaling If this feature isn't available, and not all prefixes fit in the RA (in the form of PIO or LPIOs), then the host has to guess following CPL logic. Note that the "no" answer can be incorrect when the routers haven't converged to a consistent state, but that will be a very infrequent case so the host can still believe the "no" and switch, and then later find out that the old prefix is also on this link. But the landmark option with a "NO" bit might be a conceptually cleaner way to describe the semantics if the "no" answer. Erik
I think Sathya wanted it for use mainly in multicast RAs to allow an explicit negative answer to a prefix request for use when it is not possible to fit a complete RA. I don't think this is necessary. I was thinking that a NAck would be good for the unicast case to help tie the answer to the question for the case when a host moves rapidly back and forth between links and gets the RS/RA sequence out of order. I'm now thinking that that's a pretty narrow special case. Erik mentions in a later email that the explicit "no" is useful for allowing immediate reconfiuration rather than CPL, but we could specify that the DNA flag set plus Landmark not present = explicit no. The only thing missing then is the link to what the router is saying no to, but that only really matters (in the unicast case) if fast movements can cause the RS/RA order to get mixed up. In short, I don't think the NAck is strictly necessary, but I'd feel more comfortable with it. How's that for a vague position... :) Brett.
> >>> If there is an LNOLO in an RA, and *in the same RA* there is PIO >>> that matches another prefix that the host believes is on the >>> current link, what should the host conclude? >>> >>> So far all have agreed that the PIO should be preferred. > > > What is the agreement? If there is a discrepancy in the response from the same router - I think its reasonable to assume something is changing in the link - changes in the prefix, number of routers etc. Assuming one implied response is more accurate than another implied response doesn't seem like the way to go? As, Erik suggested, a fall-back mechanism (with possible additional delays) to get an accurate answer seems like the best thing to do, IMHO. OK, it looks like I misinterpreted the emails as far as agreement is concerned. Brett.
Erik Nordmark wrote: > Brett Pentland wrote: > >> If there is an LNOLO in an RA, and *in the same RA* there is PIO >> that matches another prefix that the host believes is on the >> current link, what should the host conclude? > > > > This can happen in two different cases. > 1. The router is incorrect and produces an inconsistent RA; the same prefix is in a PIO and the LNOLO. > 2. The host and router are out of synch (perhaps due to flash renumbering and reassignment) but the RA itself is self-consistent. > > For #2 I think we need to look into the larger inconsistency picture. > For #1 we could declare such an RA as inconsistent and have the host drop it (the same way a host drops an RA as part of the validation rules in RFC 2461) I hadn't even considered 1., but dropping it seems like a good idea. Brett.
>>So I have a basic question about LNOLO:
>>> >
>>> >
>>> > Why do we need it?
>>> >
>>> > If the host solicits and the prefix isn't on the link, then the host
>>> > probably wants enough information that it can start configuring for the
new
>>> > link. A "no" answer isn't sufficient. So why not just send that
information
>>> > and do away with LNOLO?
>
>>
>> I think the semantics of "no, AFAIK that landmark prefix isn't on this
>> link" is a useful one, because the host can immediately take it at face
>> value and
>> - immediately discard its old prefixes, default routers
>> - immediately for a new CoA and initiate MIP type signaling
>>
>> If this feature isn't available, and not all prefixes fit in the RA (in
>> the form of PIO or LPIOs), then the host has to guess following CPL logic.
>>
So I guess this is the key point: that not all prefixes might fit in the RA
if you include the router's own PL and the DNAO. If they don't, then the
host is left guessing about whether the requested landmark is on the link in
the event the router didn't manage to fit it in.
One possibility is to just say that deployments should limit the number of
prefixes they configure on a link to avoid this problem. Will it really be
so many? Other protocols (I'm thinking of DNS) do this. Do we really have to
include some kind of NAK?
Another is to put some kind of "More" bit into the DNAO that indicates more
prefixes are on the link, and the host can solicit again, using some kind of
indication that this is a followup. This would be a killer for performance,
but should be rare if deployments limit the number of prefixes they
configure on a link.
Another is to put a NAK in the unicast (see below about multicast).
>> Note that the "no" answer can be incorrect when the routers haven't
>> converged to a consistent state, but that will be a very infrequent case
>> so the host can still believe the "no" and switch, and then later find
>> out that the old prefix is also on this link.
>>
I sent out a suggested algorithm about how to facilitate convergence,
perhaps that would help.
>> But the landmark option with a "NO" bit might be a conceptually cleaner
>> way to describe the semantics if the "no" answer.
>>
I'm still opposed to anything in the multicast RA that depends on
information in the RSs, due to the issue of DoS. If we want to use multicast
to handle DoS, then we can't allow the RSs to control what's in it,
otherwise, an attacker can easily overwhelm the MTU and otherwise bias the
RA to its advantage. Also, for simplicity, I think multicast RAs should look
pretty much alike regardless of why it is being done (run out of tokens,
beacon, etc.) since it is serving essentially the same function.
jak
Brett - <snip> >> In short, I don't think the NAck is strictly necessary, but I'd feel >> more comfortable with it. How's that for a vague position... :) I like it too - but the point Jim made about the attack scenario where a host can just generate random prefixes bothers me. Apart from being able to drain the tokens, a host can also make the router remember a lot of random-prefix-question to be responded to (SEND can not protect against either of these attacks, AFAIK). If there is no LNOLO, the router will have to only remember the positive responses, i.e. the PIOs it MUST include in the response. - Sathya
>I like it too - but the point Jim made about the attack scenario where a
host can just generate random prefixes bothers me. Apart from being able to
drain the tokens, a host can also make the router remember a lot of
random-prefix-question to be responded to (SEND can not protect against
either of these attacks, AFAIK). If there is no LNOLO, the router will have
to only remember the positive responses, i.e. the PIOs it MUST include in
the response.
>>
Section 9.2.6 in RFC 3972:
9.2.6. Neighbor Discovery DoS Attack
This attack is described in Section 4.3.2 of [22]. In it, the
attacker bombards the router with packets for fictitious addresses on
the link, causing the router to busy itself by performing Neighbor
Solicitations for addresses that do not exist. SEND does not address
this threat because it can be addressed by techniques such as rate
limiting Neighbor Solicitations, restricting the amount of state
reserved for unresolved solicitations, and clever cache management.
These are all techniques involved in implementing Neighbor Discovery
on the router.
So, yes, SEND doesn't address it, but it is expected that the implementation
of ND will.
jak
<snip> >> Section 9.2.6 in RFC 3972: >> >> 9.2.6. Neighbor Discovery DoS Attack >> >> This attack is described in Section 4.3.2 of [22]. In it, the >> attacker bombards the router with packets for fictitious addresses on >> the link, causing the router to busy itself by performing Neighbor >> Solicitations for addresses that do not exist. SEND does not >> address this threat because it can be addressed by techniques >> such as rate >> limiting Neighbor Solicitations, restricting the amount of state >> reserved for unresolved solicitations, and clever cache management. >> These are all techniques involved in implementing Neighbor >> Discovery on the router. >> >> So, yes, SEND doesn't address it, but it is expected that the >> implementationof ND will. Atleast w.r.t the token drain attack, rate limiting doesn't help because it is the rate limiting mechanism that is being attacked ;) I don't know if this is a big a problem, may be I am just pessimistic or something. But, since we fall back to one response every 3 second after the token bucket is empty, the whole FastRA component of DNA solution can be made useless very simply. - Sathya
Sathya Narayanan wrote: > Brett - > > <snip> > >> In short, I don't think the NAck is strictly necessary, but I'd >> feel more comfortable with it. How's that for a vague position... >> :) > > > > I like it too - but the point Jim made about the attack scenario > where a host can just generate random prefixes bothers me. Apart from > being able to drain the tokens, a host can also make the router > remember a lot of random-prefix-question to be responded to (SEND can > not protect against either of these attacks, AFAIK). If there is no > LNOLO, the router will have to only remember the positive responses, > i.e. the PIOs it MUST include in the response. > The total number to be remembered (positives + negatives) is limited by the token bucket size. After that, if the router falls back to multicast completeRAs, it doesn't have to remember any of the questions. Brett.
Sathya Narayanan wrote: > <snip> > >> Section 9.2.6 in RFC 3972: >> >> 9.2.6. Neighbor Discovery DoS Attack >> >> This attack is described in Section 4.3.2 of [22]. In it, the attacker bombards the router with packets for fictitious addresses >> on the link, causing the router to busy itself by performing >> Neighbor Solicitations for addresses that do not exist. SEND does >> not address this threat because it can be addressed by techniques >> such as rate limiting Neighbor Solicitations, restricting the >> amount of state reserved for unresolved solicitations, and clever >> cache management. These are all techniques involved in implementing >> Neighbor Discovery on the router. >> >> So, yes, SEND doesn't address it, but it is expected that the implementationof ND will. > > > Atleast w.r.t the token drain attack, rate limiting doesn't help > because it is the rate limiting mechanism that is being attacked ;) I > don't know if this is a big a problem, may be I am just pessimistic > or something. But, since we fall back to one response every 3 second > after the token bucket is empty, the whole FastRA component of DNA > solution can be made useless very simply. > Maybe I'm oversimplifying, but an attack on the token bucket such as you are worried about seems like a non-event to me. The result would be some slow handovers - it doesn't even affect traffic flow. It would be just as simple to cause much more damage in other ways - flooding the link with multicast pakets, as a really simplistic example. Brett.
>Sathya Narayanan wrote: > >>> > Brett - >>> > >>> > <snip> >>> > >> >>>> >> In short, I don't think the NAck is strictly necessary, but I'd >>>> >> feel more comfortable with it. How's that for a vague position... >>>> >> :) >> >>> > >>> > >>> > I like it too - but the point Jim made about the attack scenario >>> > where a host can just generate random prefixes bothers me. Apart > >> from> being able to drain the tokens, a host can also make the router > >>> > remember a lot of random-prefix-question to be responded to > >> (SEND can > >>> > not protect against either of these attacks, AFAIK). If there is no >>> > LNOLO, the router will have to only remember the positive responses, >>> > i.e. the PIOs it MUST include in the response. >>> > > >> The total number to be remembered (positives + negatives) is >> limited by >> the token bucket size. After that, if the router falls back to >> multicast completeRAs, it doesn't have to remember any of the questions. We seem to be arguing in circles. I don't see the need for a LNOLO in a unicast response. If a host receives a unicast response, it knows the RA is in response to its RS and the absense of the landmark prefix in a PIO indicates a 'no' answer. Adding a LNOLO is just wasted bits on line, AFAICT. And, if multicast RA can be completeRA, that is the best, simplest thing to be done. I think everybody agrees on that - the open issue is only w.r.t in-complete multicast RA messages. - Sathya
>Sathya Narayanan wrote: > >>> > <snip> >>> > >> >>>> >> Section 9.2.6 in RFC 3972: >>>> >> >>>> >> 9.2.6. Neighbor Discovery DoS Attack >>>> >> >>>> >> This attack is described in Section 4.3.2 of [22]. In it, the >>>> >> attacker bombards the router with packets for fictitious addresses >>>> >> on the link, causing the router to busy itself by performing >>>> >> Neighbor Solicitations for addresses that do not exist. SEND does >>>> >> not address this threat because it can be addressed by techniques >>>> >> such as rate limiting Neighbor Solicitations, restricting the >>>> >> amount of state reserved for unresolved solicitations, and clever >>>> >> cache management. These are all techniques involved in implementing >>>> >> Neighbor Discovery on the router. >>>> >> >>>> >> So, yes, SEND doesn't address it, but it is expected that the >>>> >> implementationof ND will. >> >>> > >>> > Atleast w.r.t the token drain attack, rate limiting doesn't help >>> > because it is the rate limiting mechanism that is being attacked > >> ;) I > >>> > don't know if this is a big a problem, may be I am just pessimistic >>> > or something. But, since we fall back to one response every 3 second >>> > after the token bucket is empty, the whole FastRA component of DNA >>> > solution can be made useless very simply. >>> > > >> Maybe I'm oversimplifying, but an attack on the token bucket such as >> you are worried about seems like a non-event to me. The result would be >> some slow handovers - it doesn't even affect traffic flow. I don't know how one half of the whole DNA solution work becoming irrelevant be a non-event. We spent all this time designing varios fastRA mechanisms, all of which can be made useless easily. >> It would be just as simple to cause much more damage in other ways - flooding the >> link with multicast pakets, as a really simplistic example. You are probably correct on this (my pessimistic mind is not letting this go). What bothers me is that a flooding attack can be recognized, but this token bucket attack can be sneaky because the number of messages needed to achieve this is less. And the other point is, an attacker can always create interference/collisions by just transmitting random bits in WLAN channel, but that is no reason to leave higher layers open to flooding attacks. Am I rambling, or does it make sense? - Sathya
Sathya,
What about if there is not enough room in the RA for all the prefix
information (PLOs + DNAO)?
jak
----- Original Message -----
From: "Sathya Narayanan" <sathya@research.panasonic.com>
To: "Brett Pentland" <brett.pentland@eng.monash.edu.au>
Cc: "James Kempf" <kempf@docomolabs-usa.com>; <dna-dt@eng.monash.edu.au>
Sent: Tuesday, April 19, 2005 5:57 PM
Subject: Re: [DNA-DT] Solution1, Issue 9: LNOLO vs. matched prefix
>>> > Sathya Narayanan wrote:
>>
>>>> > > Brett -
>>>> > >
>>>> > > <snip>
>>>> > >
>>>
>>>>> > >> In short, I don't think the NAck is strictly necessary, but I'd
>>>>> > >> feel more comfortable with it. How's that for a vague position...
>>>>> > >> :)
>>>
>>>> > >
>>>> > >
>>>> > > I like it too - but the point Jim made about the attack scenario
>>>> > > where a host can just generate random prefixes bothers me. Apart
>>
>>> > from> being able to drain the tokens, a host can also make the router
>>
>>>> > > remember a lot of random-prefix-question to be responded to
>>
>>> > (SEND can
>>
>>>> > > not protect against either of these attacks, AFAIK). If there is no
>>>> > > LNOLO, the router will have to only remember the positive responses,
>>>> > > i.e. the PIOs it MUST include in the response.
>>>> > >
>>
>>> > The total number to be remembered (positives + negatives) is
>>> > limited by
>>> > the token bucket size. After that, if the router falls back to
>>> > multicast completeRAs, it doesn't have to remember any of the questions.
>
>>
>> We seem to be arguing in circles. I don't see the need for a LNOLO in a
unicast response. If a host receives a unicast response, it knows the RA is
in response to its RS and the absense of the landmark prefix in a PIO
indicates a 'no' answer. Adding a LNOLO is just wasted bits on line, AFAICT.
>>
>> And, if multicast RA can be completeRA, that is the best, simplest thing
to be done. I think everybody agrees on that - the open issue is only w.r.t
in-complete multicast RA messages.
>>
>> - Sathya
James Kempf wrote: > So I guess this is the key point: that not all prefixes might fit in the RA > if you include the router's own PL and the DNAO. If they don't, then the > host is left guessing about whether the requested landmark is on the link in > the event the router didn't manage to fit it in. > > One possibility is to just say that deployments should limit the number of > prefixes they configure on a link to avoid this problem. Will it really be > so many? Other protocols (I'm thinking of DNS) do this. Do we really have to > include some kind of NAK? AFAIK DNS can return an arbitrarily large answer. (It might have to fall back from UDP to TCP transport, but that doesn't change the fact that the DNS "service" can deal with arbitrarily large; it does effect the efficiency though.) > Another is to put some kind of "More" bit into the DNAO that indicates more > prefixes are on the link, and the host can solicit again, using some kind of > indication that this is a followup. This would be a killer for performance, > but should be rare if deployments limit the number of prefixes they > configure on a link. A "more bit" for DNAO might not be sufficient, because RFC 2461 allows the number of PIOs to be more than what fits in 1280. The router just sends multiple RAs when it would have sent one. > Another is to put a NAK in the unicast (see below about multicast). A NAK in the unicast is what makes sense to me. I agree with you that making all multicast RAs follow the same logic is simple and sufficient for the problem we are trying to solve. >> But the landmark option with a "NO" bit might be a conceptually cleaner >> way to describe the semantics if the "no" answer. >> > > > I'm still opposed to anything in the multicast RA that depends on > information in the RSs, due to the issue of DoS. If we want to use multicast > to handle DoS, then we can't allow the RSs to control what's in it, > otherwise, an attacker can easily overwhelm the MTU and otherwise bias the > RA to its advantage. Also, for simplicity, I think multicast RAs should look > pretty much alike regardless of why it is being done (run out of tokens, > beacon, etc.) since it is serving essentially the same function. Agreed. My point is a NAK in the unicast RA only. Erik
Erik Nordmark wrote: > > I agree with you that making all multicast RAs follow the same logic is simple and sufficient for the problem we are trying to solve. I agree with this too. Brett.
>> Maybe I'm oversimplifying, but an attack on the token bucket such >> as you are worried about seems like a non-event to me. The result >> would be some slow handovers - it doesn't even affect traffic flow. >> > > I don't know how one half of the whole DNA solution work becoming > irrelevant be a non-event. We spent all this time designing varios > fastRA mechanisms, all of which can be made useless easily. It's not that it's irrelevant; I just can't see that we can do anything about it in this space. Adding NAcks to the multicast RAs does not help much, because the NAcks for legitimate hosts will be dwarfed by those for the attacker. A few hosts might be lucky enough to get a NAck, but that doesn't seem like much of a fix. The space in the RA would be better used carrying PIOs that are valid on the link that can be used for configuration, rather than carrying NAcks for bogus RSs. > > >> It would be just as simple to cause much more damage in other ways >> - flooding the link with multicast pakets, as a really simplistic >> example. > > > > You are probably correct on this (my pessimistic mind is not letting > this go). What bothers me is that a flooding attack can be > recognized, but this token bucket attack can be sneaky because the > number of messages needed to achieve this is less. And the other > point is, an attacker can always create interference/collisions by > just transmitting random bits in WLAN channel, but that is no reason > to leave higher layers open to flooding attacks. Am I rambling, or > does it make sense? The concern makes sense; it's just that I haven't yet seen a way that we can address it in this space. Brett.
Jim - >> Sathya, >> >> What about if there is not enough room in the RA for all the prefix information (PLOs + DNAO)? I am not sure I understand the context of this question. But, this is the case (refered to as in-complete multicast RA by me below) which I don't think there is an easy answer. I used to think defining a LNOLO, allows the routers to put as many as possible specific responses, PIO for yes and LNOLOs for no, in the multicast RA. Based on our email (between you and me) exchanges y'day, I am not so sure that is a good idea. So, the simple answer is, if the router can not make a completeRA due to MTU restriction - the host will have to fall-back on CPL when it receives a multicast RA without its landmark prefix in the PIO/DNAO. thanks, Sathya
Brett Pentland wrote: > I was thinking that a NAck would be good for the unicast case to > help tie the answer to the question for the case when a host moves > rapidly back and forth between links and gets the RS/RA sequence > out of order. I'm now thinking that that's a pretty narrow special > case. But wouldn't we still need to handle that case? There isn't a hard upper limit on how long L2 propagation (and L2 retransmissions) plus router delay of the RA might take, so a host might receive a "yes" or a "no" answer in an RA after it has sent multiple different questions in a RS. Thus having these answers contain the question they respond to, seems like a simple yet useful approach. > Erik mentions in a later email that the explicit "no" is useful > for allowing immediate reconfiuration rather than CPL, but we could > specify that the DNA flag set plus Landmark not present = explicit > no. The only thing missing then is the link to what the router is > saying no to, but that only really matters (in the unicast case) if > fast movements can cause the RS/RA order to get mixed up. But "no" which of possibly multiple questions? Either we can repeat the question in the answer (which I think is what DNS does), or we can introduce a sequence number and software to deal with that. (FWIW I think DNS both repeats the question with the answer, and includes a sequence number.) > In short, I don't think the NAck is strictly necessary, but I'd feel > more comfortable with it. How's that for a vague position... :) Same here. Erik
<snip> >> >> The concern makes sense; it's just that I haven't yet seen a way that >> we can address it in this space. I agree. - Sathya
>>Section 9.2.6 in RFC 3972:
>>> >
>>> > 9.2.6. Neighbor Discovery DoS Attack
>>> >
>>> > This attack is described in Section 4.3.2 of [22]. In it, the
>>> > attacker bombards the router with packets for fictitious addresses on
>>> > the link, causing the router to busy itself by performing Neighbor
>>> > Solicitations for addresses that do not exist. SEND does not
>>> > address this threat because it can be addressed by techniques
>>> > such as rate
>>> > limiting Neighbor Solicitations, restricting the amount of state
>>> > reserved for unresolved solicitations, and clever cache management.
>>> > These are all techniques involved in implementing Neighbor
>>> > Discovery on the router.
>>> >
>>> > So, yes, SEND doesn't address it, but it is expected that the
>>> > implementationof ND will.
>
>> Atleast w.r.t the token drain attack, rate limiting doesn't help because
it is the rate limiting mechanism that is being attacked ;) I don't know if
this is a big a problem, may be I am just pessimistic or something. But,
since we fall back to one response every 3 second after the token bucket is
empty, the whole FastRA component of DNA solution can be made useless very
simply.
>>
Maybe the fact that the rate limiting mechanism can be attacked suggests
that the rate limiting mechanism we've designed is deficient. :-)
If we instead use a fixed rate (but configurable depending on link speed and
expected load), and have the router roll over to selective drop afterwards
for a certain period, then end up, when the rate finally gets too high, to
sending a multicast, it would be more robust. This is what we discussed in
SEND.
jak
Brett,
It's limited, but making the number depend on the RSs still gives the
attacker the advantage of being able to bias the multicast RA content. Thus,
any information derived from the RSs will not be of much use to anyone, and
will just serve to bloat the RA. So I still think that having all multicast
RAs have the same format is better.
jak
----- Original Message -----
From: "Brett Pentland" <brett.pentland@eng.monash.edu.au>
To: "Sathya Narayanan" <sathya@research.panasonic.com>
Cc: "James Kempf" <kempf@docomolabs-usa.com>; <dna-dt@eng.monash.edu.au>
Sent: Tuesday, April 19, 2005 5:27 PM
Subject: Re: [DNA-DT] Solution1, Issue 9: LNOLO vs. matched prefix
>> Sathya Narayanan wrote:
>
>>> > Brett -
>>> >
>>> > <snip>
>>> >
>>
>>>> >> In short, I don't think the NAck is strictly necessary, but I'd
>>>> >> feel more comfortable with it. How's that for a vague position...
>>>> >> :)
>>
>>> >
>>> >
>>> > I like it too - but the point Jim made about the attack scenario
>>> > where a host can just generate random prefixes bothers me. Apart from
>>> > being able to drain the tokens, a host can also make the router
>>> > remember a lot of random-prefix-question to be responded to (SEND can
>>> > not protect against either of these attacks, AFAIK). If there is no
>>> > LNOLO, the router will have to only remember the positive responses,
>>> > i.e. the PIOs it MUST include in the response.
>>> >
>
>> The total number to be remembered (positives + negatives) is limited by
>> the token bucket size. After that, if the router falls back to
>> multicast completeRAs, it doesn't have to remember any of the questions.
>>
>> Brett.
Sathya,
Just because there is one kind of attack possible that is fairly broad (like
opening a microwave oven in an 802.11 cell) doesn't mean that we should
avoid designing the protocol to avoid more subtle attacks. There are lots of
examples of attackers taking advantage of subtle bugs, when it would also
have been possible to simply flood a link with packets.
jak
----- Original Message -----
From: "Sathya Narayanan" <sathya@research.panasonic.com>
To: "Brett Pentland" <brett.pentland@eng.monash.edu.au>
Cc: "James Kempf" <kempf@docomolabs-usa.com>; <dna-dt@eng.monash.edu.au>
Sent: Tuesday, April 19, 2005 6:08 PM
Subject: Re: [DNA-DT] Solution1, Issue 9: LNOLO vs. matched prefix
>>> > Sathya Narayanan wrote:
>>
>>>> > > <snip>
>>>> > >
>>>
>>>>> > >> Section 9.2.6 in RFC 3972:
>>>>> > >>
>>>>> > >> 9.2.6. Neighbor Discovery DoS Attack
>>>>> > >>
>>>>> > >> This attack is described in Section 4.3.2 of [22]. In it, the
>>>>> > >> attacker bombards the router with packets for fictitious addresses
>>>>> > >> on the link, causing the router to busy itself by performing
>>>>> > >> Neighbor Solicitations for addresses that do not exist. SEND does
>>>>> > >> not address this threat because it can be addressed by techniques
>>>>> > >> such as rate limiting Neighbor Solicitations, restricting the
>>>>> > >> amount of state reserved for unresolved solicitations, and clever
>>>>> > >> cache management. These are all techniques involved in implementing
>>>>> > >> Neighbor Discovery on the router.
>>>>> > >>
>>>>> > >> So, yes, SEND doesn't address it, but it is expected that the
>>>>> > >> implementationof ND will.
>>>
>>>> > >
>>>> > > Atleast w.r.t the token drain attack, rate limiting doesn't help
>>>> > > because it is the rate limiting mechanism that is being attacked
>>
>>> > ;) I
>>
>>>> > > don't know if this is a big a problem, may be I am just pessimistic
>>>> > > or something. But, since we fall back to one response every 3 second
>>>> > > after the token bucket is empty, the whole FastRA component of DNA
>>>> > > solution can be made useless very simply.
>>>> > >
>>
>>> > Maybe I'm oversimplifying, but an attack on the token bucket such as
>>> > you are worried about seems like a non-event to me. The result would be
>>> > some slow handovers - it doesn't even affect traffic flow.
>
>> I don't know how one half of the whole DNA solution work becoming
irrelevant be a non-event. We spent all this time designing varios fastRA
mechanisms, all of which can be made useless easily.
>>
>
>>> > It would be just as simple to cause much more damage in other ways -
flooding the
>>> > link with multicast pakets, as a really simplistic example.
>
>>
>> You are probably correct on this (my pessimistic mind is not letting this
go). What bothers me is that a flooding attack can be recognized, but this
token bucket attack can be sneaky because the number of messages needed to
achieve this is less. And the other point is, an attacker can always create
interference/collisions by just transmitting random bits in WLAN channel,
but that is no reason to leave higher layers open to flooding attacks. Am I
rambling, or does it make sense?
>>
>> - Sathya
>>
>>
Ditto.
jak
----- Original Message -----
From: "Brett Pentland" <brett.pentland@eng.monash.edu.au>
To: "Erik Nordmark" <erik.nordmark@sun.com>
Cc: "James Kempf" <kempf@docomolabs-usa.com>; <dna-dt@eng.monash.edu.au>
Sent: Tuesday, April 19, 2005 6:25 PM
Subject: Re: [DNA-DT] Solution1, Issue 9: LNOLO vs. matched prefix
>> Erik Nordmark wrote:
>
>>> >
>>> > I agree with you that making all multicast RAs follow the same logic is
>>> > simple and sufficient for the problem we are trying to solve.
>
>>
>> I agree with this too.
>>
>> Brett.
Jim - > Sathya, > > Just because there is one kind of attack possible that is fairly broad (like > opening a microwave oven in an 802.11 cell) doesn't mean that we should > avoid designing the protocol to avoid more subtle attacks. There are lots of > examples of attackers taking advantage of subtle bugs, when it would also > have been possible to simply flood a link with packets. > > This was exactly my point ;-) I guess I really need to work on my writing skills - this is what I meant by saying " but that is no reason to leave higher layers open to flooding attacks". This is exactly the reason I am worried about the token-bucket scheme we have, becuase it is a more subtle problem and allows an attacker to increase the DNA delay. - Sathya > jak > > ----- Original Message ----- From: "Sathya Narayanan" <sathya@research.panasonic.com> > To: "Brett Pentland" <brett.pentland@eng.monash.edu.au> > Cc: "James Kempf" <kempf@docomolabs-usa.com>; <dna-dt@eng.monash.edu.au> > Sent: Tuesday, April 19, 2005 6:08 PM > Subject: Re: [DNA-DT] Solution1, Issue 9: LNOLO vs. matched prefix > > > > >>> Sathya Narayanan wrote: >>> >>> >>>> <snip> >>>> >>>> >>>> >>>>> Section 9.2.6 in RFC 3972: >>>>> >>>>> 9.2.6. Neighbor Discovery DoS Attack >>>>> >>>>> This attack is described in Section 4.3.2 of [22]. In it, the >>>>> attacker bombards the router with packets for fictitious addresses >>>>> on the link, causing the router to busy itself by performing >>>>> Neighbor Solicitations for addresses that do not exist. SEND does >>>>> not address this threat because it can be addressed by techniques >>>>> such as rate limiting Neighbor Solicitations, restricting the >>>>> amount of state reserved for unresolved solicitations, and clever >>>>> cache management. These are all techniques involved in implementing >>>>> Neighbor Discovery on the router. >>>>> >>>>> So, yes, SEND doesn't address it, but it is expected that the >>>>> implementationof ND will. >>>>> >>>> >>>> Atleast w.r.t the token drain attack, rate limiting doesn't help >>>> because it is the rate limiting mechanism that is being attacked >>>> >>> >>> ;) I >>> >>> >>>> don't know if this is a big a problem, may be I am just pessimistic >>>> or something. But, since we fall back to one response every 3 second >>>> after the token bucket is empty, the whole FastRA component of DNA >>>> solution can be made useless very simply. >>>> >>>> >>> >>> Maybe I'm oversimplifying, but an attack on the token bucket such as >>> you are worried about seems like a non-event to me. The result would be >>> some slow handovers - it doesn't even affect traffic flow. >>> >> >> I don't know how one half of the whole DNA solution work becoming >> > > irrelevant be a non-event. We spent all this time designing varios fastRA > mechanisms, all of which can be made useless easily. > > >>> It would be just as simple to cause much more damage in other ways - >>> > > flooding the > > >>> link with multicast pakets, as a really simplistic example. >>> >> >> You are probably correct on this (my pessimistic mind is not letting this >> > > go). What bothers me is that a flooding attack can be recognized, but this > token bucket attack can be sneaky because the number of messages needed to > achieve this is less. And the other point is, an attacker can always create > interference/collisions by just transmitting random bits in WLAN channel, > but that is no reason to leave higher layers open to flooding attacks. Am I > rambling, or does it make sense? > > >> - Sathya
James Kempf wrote: > <snip> > > > Maybe the fact that the rate limiting mechanism can be attacked suggests > that the rate limiting mechanism we've designed is deficient. :-) > > If we instead use a fixed rate (but configurable depending on link speed and > expected load), and have the router roll over to selective drop afterwards > for a certain period, then end up, when the rate finally gets too high, to > sending a multicast, it would be more robust. This is what we discussed in > SEND. > > Yes. I am in favor of your suggestion to do some kinda selective drop mechanism. I think it takes away the deterministic behavior of routers w.r.t. the token bucket and makes it difficult to be attacked. Ofcourse, we need work out the details. Sathya
James Kempf wrote: >>> Section 9.2.6 in RFC 3972: >>> >>> 9.2.6. Neighbor Discovery DoS Attack >>> >>> This attack is described in Section 4.3.2 of [22]. In it, the >>> attacker bombards the router with packets for fictitious addresses on >>> the link, causing the router to busy itself by performing Neighbor >>> Solicitations for addresses that do not exist. SEND does not >>> address this threat because it can be addressed by techniques >>> such as rate >>> limiting Neighbor Solicitations, restricting the amount of state >>> reserved for unresolved solicitations, and clever cache management. >>> These are all techniques involved in implementing Neighbor >>> Discovery on the router. >>> >>> So, yes, SEND doesn't address it, but it is expected that the >>> implementationof ND will. >> >> >> Atleast w.r.t the token drain attack, rate limiting doesn't help because > > > it is the rate limiting mechanism that is being attacked ;) I don't know if > this is a big a problem, may be I am just pessimistic or something. But, > since we fall back to one response every 3 second after the token bucket is > empty, the whole FastRA component of DNA solution can be made useless very > simply. > > > Maybe the fact that the rate limiting mechanism can be attacked suggests > that the rate limiting mechanism we've designed is deficient. :-) > > If we instead use a fixed rate (but configurable depending on link speed and > expected load), and have the router roll over to selective drop afterwards > for a certain period, then end up, when the rate finally gets too high, to > sending a multicast, it would be more robust. This is what we discussed in > SEND. But if we use a fixed rate, then we won't be able to respond quickly to bursts of RSs such as when several host move at approximately the same time, will we? Brett.
So do I :) I just meant that a router sometimes has to wait before it can send it's unicast reply because of the FastRA scheme, and so it has to remember the answer, and the number it has to remember is limited by the token bucket size. Any additional RSs would not need to be individually remembered because they will be dealt with by a multicast completeRA (that is the same as all other multicast RAs in sends) Brett. James Kempf wrote: > Brett, > > It's limited, but making the number depend on the RSs still gives the > attacker the advantage of being able to bias the multicast RA content. Thus, > any information derived from the RSs will not be of much use to anyone, and > will just serve to bloat the RA. So I still think that having all multicast > RAs have the same format is better. > > jak > > ----- Original Message ----- From: "Brett Pentland" <brett.pentland@eng.monash.edu.au> > To: "Sathya Narayanan" <sathya@research.panasonic.com> > Cc: "James Kempf" <kempf@docomolabs-usa.com>; <dna-dt@eng.monash.edu.au> > Sent: Tuesday, April 19, 2005 5:27 PM > Subject: Re: [DNA-DT] Solution1, Issue 9: LNOLO vs. matched prefix > > > >> Sathya Narayanan wrote: >> >>> Brett - >>> >>> <snip> >>> >>>> In short, I don't think the NAck is strictly necessary, but I'd >>>> feel more comfortable with it. How's that for a vague position... >>>> :) >>> >>> >>> >>> I like it too - but the point Jim made about the attack scenario >>> where a host can just generate random prefixes bothers me. Apart from >>> being able to drain the tokens, a host can also make the router >>> remember a lot of random-prefix-question to be responded to (SEND can >>> not protect against either of these attacks, AFAIK). If there is no >>> LNOLO, the router will have to only remember the positive responses, >>> i.e. the PIOs it MUST include in the response. >>> >> >> The total number to be remembered (positives + negatives) is limited by >> the token bucket size. After that, if the router falls back to >> multicast completeRAs, it doesn't have to remember any of the questions. >> >> Brett.
Sathya Narayanan wrote: > James Kempf wrote: > >> <snip> >> >> >> Maybe the fact that the rate limiting mechanism can be attacked suggests >> that the rate limiting mechanism we've designed is deficient. :-) >> >> If we instead use a fixed rate (but configurable depending on link speed and >> expected load), and have the router roll over to selective drop afterwards >> for a certain period, then end up, when the rate finally gets too high, to >> sending a multicast, it would be more robust. This is what we discussed in >> SEND. >> >> > Yes. I am in favor of your suggestion to do some kinda selective drop mechanism. I think it takes away the deterministic behavior of routers w.r.t. the token bucket and makes it difficult to be attacked. Ofcourse, we need work out the details. Sorry for needing to be told again, but I'm still not understanding how this will work. An RS arrives at a router. What is the algorithm for the router deciding to answer unicast, multicast or drop? Brett.
>>>>Section 9.2.6 in RFC 3972:
>>>>> >>>
>>>>> >>>9.2.6. Neighbor Discovery DoS Attack
>>>>> >>>
>>>>> >>> This attack is described in Section 4.3.2 of [22]. In it, the
>>>>> >>> attacker bombards the router with packets for fictitious addresses on
>>>>> >>> the link, causing the router to busy itself by performing Neighbor
>>>>> >>> Solicitations for addresses that do not exist. SEND does not
>>>>> >>>address this threat because it can be addressed by techniques
>>>>> >>>such as rate
>>>>> >>> limiting Neighbor Solicitations, restricting the amount of state
>>>>> >>> reserved for unresolved solicitations, and clever cache management.
>>>>> >>> These are all techniques involved in implementing Neighbor
>>>>> >>>Discovery on the router.
>>>>> >>>
>>>>> >>>So, yes, SEND doesn't address it, but it is expected that the
>>>>> >>>implementationof ND will.
>>>
>>>> >>
>>>> >>Atleast w.r.t the token drain attack, rate limiting doesn't help because
>>
>>> >
>>> > it is the rate limiting mechanism that is being attacked ;) I don't know
if
>>> > this is a big a problem, may be I am just pessimistic or something. But,
>>> > since we fall back to one response every 3 second after the token bucket
is
>>> > empty, the whole FastRA component of DNA solution can be made useless
very
>>> > simply.
>>> >
>>> >
>>> > Maybe the fact that the rate limiting mechanism can be attacked suggests
>>> > that the rate limiting mechanism we've designed is deficient. :-)
>>> >
>>> > If we instead use a fixed rate (but configurable depending on link speed
and
>>> > expected load), and have the router roll over to selective drop
afterwards
>>> > for a certain period, then end up, when the rate finally gets too high,
to
>>> > sending a multicast, it would be more robust. This is what we discussed
in
>>> > SEND.
>
>>
>> But if we use a fixed rate, then we won't be able to respond quickly to
>> bursts of RSs such as when several host move at approximately the same
>> time, will we?
>>
Actually, I think it might be better than the token bucket. There are only
so many tokens in the bucket. If enough hosts move to exhaust the bucket,
then the losers must wait until the multicast RA (3 sec. according to
current thinking). The algorithm I proposed would continue to send RSs but
would drop selectively. So, at least some of the RSs would get an immediate
response. If the hosts retransmit, then they are likely to all get a unicast
response from the retransmit before the multicast RA if the problem is
simply a burst and not DoS, because the drop algorithm treats the burst like
transient congestion (actually, it is transient congestion, too many packets
for available bandwidth), if the burst is shorter than the multicast RA
duration. If its longer, then the router switches to multicast until the
packet arrival rate settles down, or somebody wakes up and finds the
attacker.
jak
| Topic DNASoln1Issue009 . { Edit | Attach | Ref-By | Printable | Diffs | r1.5 | > | r1.4 | > | r1.3 | More } |
|
Revision r1.5 - 22 Apr 2005 - 02:11 GMT - Main.BrettPentland Parents: WebHome > DNASolution1 |
Copyright © 1999-2003 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback. |