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

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Wed, 24 Apr 2002 17:31:00 -0400 (EDT)

Answering Tony Li's comments on my comments (my original comments have
a line in front, and are most indented, Tony's comments are indented
and unlined):
	 | 1) I'd assume that SNPs should use the link secret, since they are
	 | not forwarded

	Yes, but they can be replicated on multiple links.  This simplifies
	implementation.
	
I guess the CSNP would be identical on each link, but a PSNP would not.
But I guess that's a plausible reason for making it the area secret.
	
	 | 2) I remember IS-IS having a set of acceptable receive secrets,
	 | and a single transmit password, so that secret rollover wouldn't
	 | be a problem. This draft seems to imply there's only a single one.

	That is certainly an implementation option.
	
Wouldn't it affect the management, i.e., that setting the receive secret
would involve a set of things rather than a single thing? I think it's
important to do this (allow multiple receive secrets)
so it is easy to migrate from one secret to another. I remember designing
that for IS-IS a long time ago, and being very explicit about the multiple
receive secrets. Is there still text around in some document recommending
this, or does all the text these days mention a single secret? Does
the MIB allow setting multiple receive secrets?
	
	 | 3) Shouldn't there be a separate layer 1 and layer 2 link secret?
	 | (Again, I think I remember that from DECnet).

	What is gained from this?
So that layer 1 routers can't generate layer 2 messages (and vice versa).	
	
	[Side question: what is gained from multiple
	secrets anyhow?]
Do you mean layer 1 plus layer 2 secrets? That's to keep each logical
trust group separate. Or do you mean multiple receive secrets? That's
for easy secret rollover. To get from secret a to secret b, one
by one have routers add secret b to their allowable receive secrets.
Then once everyone accepts both, one by one change their transmit
secret to b. Once everyone has their transmit secret as b, then
one by one remove a from the acceptable receive set.	
	
	I know of no installations where someone would allow an
	L1 adjacency but not an L2.  Seems like it could be simplified...
	
Well again, working from ancient memory...it was designed so that
L2 routers could form adjacencies over the same wire as L1 routers,
and even allowed mutliple L1 areas on the same LAN. It's good
cryptographic practice to have each separate community of trust have
a different secret.

Radia

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

---

From: Alex Zinin <[email-masked]>
Date: Wed, 24 Apr 2002 15:35:56 -0700

Radia,

        
> the MIB allow setting multiple receive secrets?
        
The draft actually talks about this:

       An  implementation MAY check a set of passwords when verifying the
    Authentication Value.  This provides a  mechanism  for  incrementally
    changing passwords in a network.

I don't know about the MIB part.

Cheers!

Alex

---

From: Tony Li <[email-masked]>
Date: Wed, 24 Apr 2002 17:19:37 -0700

Radia

 | Well again, working from ancient memory...it was designed so that
 | L2 routers could form adjacencies over the same wire as L1 routers,
 | and even allowed mutliple L1 areas on the same LAN. It's good
 | cryptographic practice to have each separate community of trust have
 | a different secret.

My point is that in modern deployment, the trust area is the entire routing
domain.

And not one more micron.  ;-)

Tony