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

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Oct 2011 15:06:30 -0700

I have a comment regarding the recently published draft:

http://tools.ietf.org/id/draft-chunduri-isis-extended-sequence-no-tlv-00
.txt

In regards to the use of the new TLV in LSPs, it isn't clear to me what
the value add is if cryptographic authentication (RFC 5304 or RFC 5310)
is in use?

The draft states in Section 2.2:

" Today Link State PDUs (LSPs) have intra-session replay protection as
   LSP header contains 32-bit sequence number which is verified for
   every received packet against the local LSP database.  But, if the
   key is not changed, an adversary can cause an inter-session replay
   attack by replaying a old LSP with higher sequence number and fewer
   prefixes or fewer adjacencies."

If no authentication or plain text password authentication were in use,
the inter-session replay attack could succeed - but with the use of
cryptographic authentication the adversary would have to have the key in
order to generate an LSP which would pass authentication checks.

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.

I also wish to point out that in the event of 32 bit sequence # rollover
(something which would take roughly 136 years if a new LSP were
generated once/second) ISO 10589 Section 7.3.16.1 states:

"If an Intermediate system needs to increment its sequence number, but
the sequence number is already equal to SequenceModulus - 1, the event
attemptToExceedMaxi-mumSequenceNumber shall be generated and the IS
Network entity shall be disabled for a period of at least MaxAge +
ZeroAgeLifetime, in order to be sure that any versions of this LSP with
the high sequence number have expired. When it is re-enabled the IS
shall start again with sequence number 1."

which seems to make moot the value of the Extended Session Sequence
Number and in particular makes the stipulations in Section 3.1 not very
useful to LSPs.

In the above context, can you comment on the value add of the new TLV
for LSPs?

Thanx.

   Les

---

From: Naiming Shen <[email-masked]>
Date: Wed, 26 Oct 2011 22:20:49 -0700

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.

thanks.
- Naiming

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Oct 2011 22:27:11 -0700

> -----Original Message-----
> From: Naiming Shen (naiming)
> Sent: Wednesday, October 26, 2011 10:21 PM
> To: Les Ginsberg (ginsberg)
> Cc: [email-masked]; [email-masked];
> [email-masked]; isis mailing list
> Subject: Re: Question regarding draft-chunduri-isis-extended-sequence-
> no-tlv-00
> 
> 
> Les,
> 

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.

   Les

---

From: Naiming Shen <[email-masked]>
Date: Wed, 26 Oct 2011 22:40:55 -0700

> limited to the transitory (and rare) case I mentioned - it is not an

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.

- Naiming

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Oct 2011 22:56:27 -0700

> Sent: Wednesday, October 26, 2011 10:41 PM
> >> But in your example, if I have a way to capture and replay your
> seq#X,
> >> then I may

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

---

From: Naiming Shen <[email-masked]>
Date: Thu, 27 Oct 2011 11:48:46 -0700

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

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 27 Oct 2011 16:14:02 -0400

Firstly, Thanks Les the analysis and for bringing-up the discussion.

Just to add what Naiming said below:
- This can happen to all the LSP fragments from the node in question.
- also, before traffic disruption there is processing involved (SPF, rt download)
  in processing the replayed LSP for all the nodes in the area or domain. This 
  processing extends to the correct new LSP received again by  all the nodes.

Uma 

-----Original Message-----
From: Naiming Shen [mailto:[email-masked]] 
Sent: Thursday, October 27, 2011 11:49 AM
To: Les Ginsberg
Cc: Uma Chunduri; Wenhu Lu; Albert Tian; isis mailing list
Subject: Re: Question regarding draft-chunduri-isis-extended-sequence-no-tlv-00

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:

>>>> 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.
>>> 
>> 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.
> 
> 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.
>

---

From: Mike Shand <[email-masked]>
Date: Thu, 27 Oct 2011 22:43:54 +0100

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:
>>>>> brief disruption,
>>> there may be
>> 1)You can send saved copies of LSP #0 w Seq #<= 100 OLD-TLVS. These
>> 3)You can send LSP #0 w Seq #>  101 OLD-TLVs, but since you don't have
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Naiming Shen <[email-masked]>
Date: Thu, 27 Oct 2011 15:12:51 -0700

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
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 27 Oct 2011 17:38:12 -0700

I started this thread to ask what value add the new TLV has when used in
LSPs. So far, the discussion has focused on a corner case wherein:

a)The attacker needs to store old LSPs in the hopes that the originating
router will be shutdown sometime in the future - a time which may be
weeks or months after the attacker begins collecting the old LSPs

b)The router to be attacked must shutdown for a period greater than LSP
lifetime

c)The attacker must notice that the router to be attacked has shutdown
and wait for LSPs to be aged out from all routers in the network

IF all of the above are met the attacker may then cause disruption for a
period of time which is proportional to the number of old LSPs it has
stored - and the disruption period associated with each LSP version
would be a modest period.

Now, is this the sole usefulness of the new TLV in LSPs? AFAICT it is -
but I am asking the authors to speak to this point in case I have
overlooked something.

If this is the sole use case for the new TLV in LSPs, then I think a
legitimate question is whether this is a problem worth solving. The
"security hole" can only be used on rare occasions and  isn't guaranteed
to provide any opportunity to cause disruption (the router which is
shutdown may be taken out of service permanently - or be restarted with
a new identity - or not be out of service long enough to allow old LSPs
to be aged out) and the duration of the disruption is bounded even on
those rare occasions when the opportunity presents itself. This isn't a
compelling justification.

   Les

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Naiming Shen (naiming)
> Sent: Thursday, October 27, 2011 3:13 PM
> To: Mike Shand
> Cc: [email-masked]
> Subject: Re: [Isis-wg] Question regardingdraft-chunduri-isis-extended-
> sequence-no-tlv-00
> 
> 
> Hi Mike,
> 
> You are correct of course. I was just saying this 30 seconds the
hacker
> does not have
> 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
> 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
> > 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
> >> your routers. This week the hacker noticed this router had reset
the
> LSP seq#.
> >> this can go on and on until the hacker runs out its seq#5000.
Assume
> each round
> >>>>>> If you were going to update the LSP to seq#X+1, which does
cause
> a
> >>>>> In order to cause disruption you have to change the content of
> the
> >>>> LSP
> >>>>> unnecessarily consuming some CPU time). Once you do that you
MUST
> >>>> have
> >>>>> limited to the transitory (and rare) case I mentioned - it is
not
> an
> >>>> your content in different LSPs. so there is no guarantee that the
> same
> >>>> LSP
> >>> I get shutdown for a week and restarted (cold start) and I send
LSP
> #0
> Again
> >>> this will have valid authentication but as the content is
unchanged
> it
> >>>>>>> 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

---

From: Naiming Shen <[email-masked]>
Date: Thu, 27 Oct 2011 18:18:18 -0700

My opinion is this:

- We know we need to have this TLV in non-LSP ISIS packets for obvious
   reasons
- We know there is a security hole even with LSP which already has
   seq# and authentications, it does not matter how small the hole is.
   thus we probably should not say this TLV is not allowed in the LSP packet
- Operators can make this decision (to use this TLV or not inside the LSP packet)
  base on whatever they see their network security requirements

- Naiming

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 27 Oct 2011 18:25:35 -0700

Naiming -

> Sent: Thursday, October 27, 2011 6:18 PM
> Cc: Mike Shand; [email-masked]

I don't think we have consensus on this yet. I have other concerns
regarding SNPs and IIHs which I have not yet raised as I thought it
would be easier to discuss one PDU at a time. :-)

I also think Manav has raised an excellent point and would like to see
his question addressed.

>    seq# and authentications, it does not matter how small the hole is.

I think this is also debatable. Changes to the protocol come at a cost -
both to the protocol vendors and the users of the protocol. I do not
share your opinion that all potential security issues have to be
addressed. A prudent evaluation of the risks and the costs needs to be
made.

   Les

> > I started this thread to ask what value add the new TLV has when
used
> in
> > Now, is this the sole usefulness of the new TLV in LSPs? AFAICT it
is
> -
> > those rare occasions when the opportunity presents itself. This
isn't
> >> 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
> >> We can change the parameters also, instead of capturing for 3
> months,
> >> he/she can do for years.
> >> 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
> >>
> >>>> 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
> >>>>>>>> then I would release the seq#X+2. and this can go on and on
> and
> >>>>>> cause
> >>>>>>>> a major disruption.
> >>>>>> some changes during the months in operation. and you can also
> re-
> >>>>>> shifting
> >>>>> 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
> >>>>> matching my local copy and I immediately generate and flood LSP
> #0
> >> Seq
> >>>>> 3)You can send LSP #0 w Seq #>  101 OLD-TLVs, but since you
don't
> >>>>> lasts only briefly and your opportunity only arises in cases
> where
> >> a