Re: Question regardingdraft-chunduri-isis-extended-sequence-no-tlv-00

Naiming -

> -----Original Message-----
> From: Naiming Shen (naiming)
> Sent: Thursday, October 27, 2011 6:18 PM
> To: Les Ginsberg (ginsberg)
> Cc: Mike Shand; isis-wg <at> ietf.org
> Subject: Re: [Isis-wg] Question regardingdraft-chunduri-isis-extended-
> sequence-no-tlv-00
> 
> 
> My opinion is this:
> 
> - We know we need to have this TLV in non-LSP ISIS packets for obvious
>    reasons

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.

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

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

>    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
> 
> On Oct 27, 2011, at 5:38 PM, Les Ginsberg (ginsberg) wrote:
> 
> > 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
> >
> >> -----Original Message-----
> >> From: isis-wg-bounces <at> ietf.org [mailto:isis-wg-bounces <at> ietf.org] On
> >> Behalf Of Naiming Shen (naiming)
> >> Sent: Thursday, October 27, 2011 3:13 PM
> >> To: Mike Shand
> >> Cc: isis-wg <at> ietf.org
> >> 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
> >> 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: uma.chunduri <at> ericsson.com; wenhu.lu <at> ericsson.com;
> >>>>>> albert.tian <at> ericsson.com; 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: uma.chunduri <at> ericsson.com; wenhu.lu <at> ericsson.com;
> >>>>>>>> albert.tian <at> ericsson.com; 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
> >>>> Isis-wg <at> ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/isis-wg
> >>>
> >>> _______________________________________________
> >>> Isis-wg mailing list
> >>> Isis-wg <at> ietf.org
> >>> https://www.ietf.org/mailman/listinfo/isis-wg
> >>
> >> _______________________________________________
> >> Isis-wg mailing list
> >> Isis-wg <at> ietf.org
> >> https://www.ietf.org/mailman/listinfo/isis-wg