Subject: RE: [Isis-wg] draft-ietf-isis-hmac-03.txt

From: "Omer Sali" <[email-masked]>
Date: Sun, 1 Jul 2001 12:42:52 +0300

Hi,

in section 2.1 it says:
"Implementations supporting the extensions described in this document
should maintain the cryptographic sequence number counter on a per-
interface basis."

Is it essential to have a different CSN for each interface ? (Clearly it
is better, but is it essential?)
Having a different CSN means that if we flood an LSP over 100 interface
we have to recalculate MD5 100 times. 

If we adopt Alex's suggestion for using only LSP's own SN we'll get over
this drawback.

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

---

From: Alex Zinin <[email-masked]>
Date: Sun, 1 Jul 2001 12:31:35 -0700

Omer,

 To make it clear, let's differentiate btw LSPs and all other
 ISIS packets. The difference is in the fact that LSPs have
 domain-wide distribution, while other packets are local to
 a specific segment.

 As far as link-local packets are concerned, everything is
 pretty much clear. We need increasing CSNs for everything
 a router sends. Maintaining one CSN for all interfaces does
 not give us any benefit, as we have to calculate HMAC anyway.

 As for LSPs, we have two options---use link-specific CSNs
 or rely on the ISIS SNs. The choice between the two is essentially
 the choice between attack prevention and attack detection.
 CSNs will provide attack prevention, as the attacker will not
 be able to replay old LSPs. ISIS SNs will not save us from
 attacks (because once an LSP has been purged, the domain loses
 the crypto state for it), i.e., the attacker will be able to
 replay LSPs, but the real originating router will be able to detect
 the attack and draw the administrator's attention to it.

 I guess I will change the draft to say CSN MAY be included
 in an LSP and if it is, the value should be taken from the
 outbound interface's CSN whenever an LSP is sent. This is
 somewhat hacky, because it breaks the main principle of
 link-state routing---"never mess with someone else's link-state
 data", but this seems to be the only choice, since we don't have LSPs
 encapsulated into some "update" packets as in OSPF.

Alex.

---

From: Derek Yeung <[email-masked]>
Date: Sun, 01 Jul 2001 16:44:31 -0700

>  be able to replay old LSPs. ISIS SNs will not save us from

	I have not follow this thread closely so my comment may be just
a misunderstanding.

	I don't expect there is any synchronization of CSN in the whole
network. So it is possible for a interface in the network has much larger
CSN for another interface in the same network. As a result, one can caputure
the LSP on the interface with larger CSN and replay it on the interface
with lower CSN and there is still no attack prevention. 

Thanks,
- Derek

---

From: Alex Zinin <[email-masked]>
Date: Sun, 1 Jul 2001 22:32:10 -0700

Derek,

> with lower CSN and there is still no attack prevention. 

Yes, a very interesting observation. Two moments here, however.
First, this assumes that the two segments are configured with the same
secret key. Second, wouldn't the attacker have to establish an adjacency with
some router on the segment before the replayed LSP is accepted? I don't recall
the ISIS spec actually saying so, but I would suspect the implementations to
do this check.

Thanks, Derek!

Alex.

---

From: Derek Yeung <[email-masked]>
Date: Mon, 02 Jul 2001 14:17:47 -0700

Alex Zinin wrote:
> secret key. 

	I suppose we are talking about LSP here, which use the same key within one area.

Second, wouldn't the attacker have to establish an adjacency with
> some router on the segment before the replayed LSP is accepted? I don't recall

	The digest in LSP does not include the MAC header, so one can fake it, right ?

	To be clear, my comment is that adding CSN to LSP does not help much.
Adding CSN to other ISIS packet type is a different issue.

- Derek

---

From: Alex Zinin <[email-masked]>
Date: Tue, 3 Jul 2001 11:48:34 -0700

Derek,

> the same key within one area.

I was thinking about using per-interface CSNs and keys.
I know it's not consistent with the nature of LSPs, i.e.
the area significance scope, but it should work.

Alex.