Subject: Re: [isis-wg] comment on hmac-03

From: Nick Amato <[email-masked]>
Date: Tue, 31 Jul 2001 22:43:51 -0400

> > Actually, even if the whole box uses a single key, this problem can
> > still occur.
> >
> > The section 2.1 is talking about a case where a key(assume for all
> > the isis packets) is rolled over at time X, and ISIS process of router A
> > restarted at that time. All the adjacencies should still come up fine
> > to use the new key. But the router can not send out it's LSP out since
> > it's neighbors still have A's old LSP(which has higher seq #), but
> > router A can't advance it's seq# because it can not authenticate the
> > old LSP it's neighbors send it back.
> 
> well, isn't the idea of a 'roll-over' that you accept both keys for a period
> of time? And during this period of time all LSPs with the old key should
> time out and any other possible information authenticated by this key
> should also vanish so obviously roll-over period >> LSP lifetime.
> Also you must be able within ISIS to hold both keys
> and when you receive a piece of information, try new key and then old
> key. Given that, what's the problem exactly ?

Just to be clear, multiple-key 'roll-over' is, according to the draft, an
optional part of this authentication (...the router MAY check a set
of passwords when verifying the Authentication value).

The problem I was addressing is that section 2.1 is unclear.  It 
should not apply to a router that implements 'roll-over' as you
define it above, rather to a case where a router can become adjacent
with N neighbors but cannot authenticate LSP packets from any of them.
Whether the router restarts or not is irrelevant.

Also for L1, CSNs use the same key as LSPs, so I'm not sure if it's
even useful to talk about LSPs here since, potentially, the router
may not be able to authenticate CSNs from the DISs (or have other routers
authenticate its CSN if it is a DIS on a circuit).

Nick
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Naiming Shen <[email-masked]>
Date: Tue, 31 Jul 2001 20:38:43 -0700

]
 ]> > Actually, even if the whole box uses a single key, this problem can
 ]> > still occur.
 ]> >
 ]> > The section 2.1 is talking about a case where a key(assume for all
 ]> > the isis packets) is rolled over at time X, and ISIS process of router A
 ]> > restarted at that time. All the adjacencies should still come up fine
 ]> > to use the new key. But the router can not send out it's LSP out since
 ]> > it's neighbors still have A's old LSP(which has higher seq #), but
 ]> > router A can't advance it's seq# because it can not authenticate the
 ]> > old LSP it's neighbors send it back.
 ]> 
 ]> well, isn't the idea of a 'roll-over' that you accept both keys for a perio
d
 ]> of time? And during this period of time all LSPs with the old key should
 ]> time out and any other possible information authenticated by this key
 ]> should also vanish so obviously roll-over period >> LSP lifetime.
 ]> Also you must be able within ISIS to hold both keys
 ]> and when you receive a piece of information, try new key and then old
 ]> key. Given that, what's the problem exactly ?
 ]
 ]Just to be clear, multiple-key 'roll-over' is, according to the draft, an
 ]optional part of this authentication (...the router MAY check a set
 ]of passwords when verifying the Authentication value).

Tony was right that in a multiple-key 'rollover', if the old key is
kept around long enough, this case should not happen.
This can happen if in the 'rollover', the new key replaces the old key,
or the old key is not kept long enough.

Or this can happen with a single key, all the routers are configured
to use authentication at time X, one router crashes right after X, and
in this case, there is no "old" key.

 ]
 ]The problem I was addressing is that section 2.1 is unclear.  It 
 ]should not apply to a router that implements 'roll-over' as you
 ]define it above, rather to a case where a router can become adjacent
 ]with N neighbors but cannot authenticate LSP packets from any of them.
 ]Whether the router restarts or not is irrelevant.
 ]
 ]Also for L1, CSNs use the same key as LSPs, so I'm not sure if it's
 ]even useful to talk about LSPs here since, potentially, the router
 ]may not be able to authenticate CSNs from the DISs (or have other routers
 ]authenticate its CSN if it is a DIS on a circuit).

I'm not sure what's this to do with csns or dis.
this was not saying LSPs are using a diff key. let's try the following case
with just two routers: A and B, they use authentication for all packets.
before time X, they use key1, after time X, they use key2.

At time X, both A and B switches auth key from key1 into key2, and A's
ISIS process restarted. A and B then re-establish the adjacency with
the key2, they can also exchange the SNPs using the key2, there is no
problem of that. A now has a LSP starts from seq# of 1. when A sends
this LSP to B, B rejects this, and send the A's old LSP back to A(with
the key1). If B does not have multiple-key implemented or B timedout
the key1 too soon, then the old LSP with key1 is rejected because of
failing authentication. B will not get A's new LSP until this old LSP
of A timed out.

 ]
 ]Nick

- Naiming

---

From: Naiming Shen <[email-masked]>
Date: Tue, 31 Jul 2001 20:50:02 -0700

]
 ]At time X, both A and B switches auth key from key1 into key2, and A's
 ]ISIS process restarted. A and B then re-establish the adjacency with
 ]the key2, they can also exchange the SNPs using the key2, there is no
 ]problem of that. A now has a LSP starts from seq# of 1. when A sends
 ]this LSP to B, B rejects this, and send the A's old LSP back to A(with
 ]the key1). If B does not have multiple-key implemented or B timedout

typo here       ^ (should be A)                             ^ ( A also )

 ]the key1 too soon, then the old LSP with key1 is rejected because of
 ]failing authentication. B will not get A's new LSP until this old LSP
 ]of A timed out.

- Naiming