Re: [Isis-wg] Question regarding draft-chunduri-isis-extended-sequence-no-tlv-00

[Naiming Shen <[e-mail]>]

Hi Mike,

You are correct of course. I was just saying this 30 seconds the hacker does not have
to follow this 300ms timing, and he/she can set this as a 30 seconds fixed interval to release the
next attack packet. Also the network routers have hold down timers for SPFs and they may
not react to changes immediately. Even if they do, we will see the network traffic disrupted
for every 30 seconds briefly for 2 days in this example.

We can change the parameters also, instead of capturing for 3 months, he/she can do for years.
Or the hacker can cause some link change events to force your router to generate LSPs
more frequently, etc. And instead of cause major disruption for 2 days, the hacker might only need
to cause trouble for 10 minutes on the net (that amount of disruption could be a WSJ frontline story).

We sure can do lots of things to minimize the impact, but the point is that the security
hole is certainly there.

thanks.
- Naiming

On Oct 27, 2011, at 2:43 PM, Mike Shand wrote:

> Hi Naiming,
> 
> I don't understand the assumption of 30 seconds per round. 300mS per round would be slow. Yes, by delaying each round by 30 seconds you could spread out the disruption, but the disruption would only last for a few 100 mS each time around, and would only affect routers between (for some value of between) you and the target router, since the target router would respond with its real LSP as soon as it saw your fake one.
> 
> But what you say is correct, in that you can store up a lot of LSPs. if you have 5000 LSPs you have around 2500 opportunities to exert some disruption, each of which will last for a few hundred mS.
> 
> Remember that for this to happen the target router has not only to have died and reset its seq number, but it has to have remained dead for at least the maximum lifetime, which in many networks these days is set to the maximum of
> 18 hours or so. If it comes back to life before then, the sequence number will get reset to the current max value of the LSPs still extant in the network, and the attacker will have no real opportunity to use his stored LSPs.
> 
>    Mike
> 
> On 27/10/2011 19:48, Naiming Shen wrote:
>> Your example is too modest. as I mentioned in the previous email, here again:
>> 
>> Let's assume the hacker was able to capture all of your LSPs in the past months,
>> and got seq# from #50 to #5000 (in 3 months assume 15 minutes each) on one of
>> your routers. This week the hacker noticed this router had reset the LSP seq#.
>> The most recent new the router sent out being lsp seq#20.
>> 
>> The hacker releases the cached/old LSP seq#50 which has very different content from
>> your current seq#20's lsp:
>> 
>> your router responds to regen seq# 51 (new)
>> hacker then replays seq# 52 (cached/old)
>> your router responds to regen seq#53 (new)
>> hacker then replays seq# 54 (cached/old)
>> ....
>> 
>> this can go on and on until the hacker runs out its seq#5000. Assume each round
>> takes 30 seconds, this disruption will last for almost 2 days in your network,
>> regardless you have authentication or not.
>> 
>> - Naiming
>> 
>> On Oct 26, 2011, at 10:56 PM, Les Ginsberg (ginsberg) wrote:
>> 
>>> 
>>>> -----Original Message-----
>>>> From: Naiming Shen (naiming)
>>>> Sent: Wednesday, October 26, 2011 10:41 PM
>>>> To: Les Ginsberg (ginsberg)
>>>> Cc: [e-mail]; [e-mail];
>>>> [e-mail]; isis mailing list
>>>> Subject: Re: Question regarding draft-chunduri-isis-extended-sequence-
>>>> no-tlv-00
>>>> 
>>>> 
>>>> On Oct 26, 2011, at 10:27 PM, Les Ginsberg (ginsberg) wrote:
>>>> 
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Naiming Shen (naiming)
>>>>>> Sent: Wednesday, October 26, 2011 10:21 PM
>>>>>> To: Les Ginsberg (ginsberg)
>>>>>> Cc: [e-mail]; [e-mail];
>>>>>> [e-mail]; isis mailing list
>>>>>> Subject: Re: Question regarding draft-chunduri-isis-extended-
>>>> sequence-
>>>>>> no-tlv-00
>>>>>> 
>>>>>> 
>>>>>> Les,
>>>>>> 
>>>>>> Even a 'very short disruption' is a disruption I would think.
>>>>>> 
>>>>>> But in your example, if I have a way to capture and replay your
>>>> seq#X,
>>>>>> then I may
>>>>>> also have a way to capture your seq#X+2, and seq#X+4, etc.
>>>>>> If you were going to update the LSP to seq#X+1, which does cause a
>>>>>> brief disruption,
>>>>>> then I would release the seq#X+2. and this can go on and on and
>>>> cause
>>>>>> a major disruption.
>>>>> In order to cause disruption you have to change the content of the
>>>> LSP
>>>>> (merely resending an identical LSP does no harm - other than
>>>>> unnecessarily consuming some CPU time). Once you do that you MUST
>>>> have
>>>>> the key in order to recalculate the correct message digest -
>>>> otherwise
>>>>> the bogus LSP fails authentication. So the problemtic scenario is
>>>>> limited to the transitory (and rare) case I mentioned - it is not an
>>>>> ongoing disruption.
>>>> But since this is your previous life's LSP, let's say last months,
>>>> there may be
>>>> some changes during the months in operation. and you can also re-
>>>> shifting
>>>> your content in different LSPs. so there is no guarantee that the same
>>>> LSP
>>>> last year will have the same content of this year.
>>> So, last week I sent LSP #0 with Seq # 100 and a certain set of TLVs
>>> (call this OLD-TLVs).
>>> I get shutdown for a week and restarted (cold start) and I send LSP #0
>>> with Seq #1 with a new set of TLVs (call this NEW-TLVs).
>>> 
>>> You as the evil attacker now send LSP #0 Seq #100 OLD-TLVs. As it has
>>> valid authentication it is accepted by routers who receive it and some
>>> disruption occurs. However once I receive it I recognize it as not
>>> matching my local copy and I immediately generate and flood LSP #0 Seq
>>> #101 NEW-TLVS. This corrects the problem.
>>> 
>>> Now you (evil attacker) have only the following options:
>>> 
>>> 1)You can send saved copies of LSP #0 w Seq #<= 100 OLD-TLVS. These
>>> will have valid authentication - but will be discarded by all routers as
>>> being older than the latest version (Seq #101) that I have previously
>>> sent.
>>> 
>>> 2)You can resend LSP #0 w Seq #101 w content unchanged (NEW-TLVs). Again
>>> this will have valid authentication but as the content is unchanged it
>>> causes no disruption.
>>> 
>>> 3)You can send LSP #0 w Seq #>  101 OLD-TLVs, but since you don't have
>>> the key authentication will fail on these LSPs and they will be
>>> discarded.
>>> 
>>> So you get one - and only one - chance to cause disruption - and this
>>> lasts only briefly and your opportunity only arises in cases where a
>>> router has cold started after being shutdown long enough for the LSPs
>>> sent by the old incarnation to be aged out from the network.
>>> 
>>>   Les
>>> 
>>>> - Naiming
>>>> 
>>>>>  Les
>>>>> 
>>>>>> thanks.
>>>>>> - Naiming
>>>>>> 
>>>>>>> 
>>>>>>> It is conceivable that if a router had generated an LSP with seq
>>> #X
>>>>>> and
>>>>>>> then shutdown for a time and then restarted sending LSP w seq#1,
>>>>> that
>>>>>>> the adversary could replay the LSP w seq #X and it would (in the
>>>>>> absence
>>>>>>> of a key change) look valid. However this would create only a very
>>>>>> short
>>>>>>> disruption - basically the time it took for the restarted router
>>> to
>>>>>>> generate and flood seq #X+1 - and thereafter attempts by the
>>>>>> adversary
>>>>>>> to generate valid looking newer versions would again fail.
>> _______________________________________________
>> Isis-wg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/isis-wg
> 
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg