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

From: "Ferrell, William" <[email-masked]>
Date: Tue, 8 Apr 2003 14:53:27 -0400

Jeff /T

Your right Jeff, absolutely right . Thats the troubles of my team...how to
mitagte the faked bits etc. How to tust our peers, MD-5 over ISIS hasnt been
standardized and the two major vendors have a slighty different
implementations.(not that MD-5 is the greatest anyway) I've gotta secure
accross our entire network, multi-vendor
I agree we cant re-start my focus is can we start to integrate the secure
perspective not only the operational view.

Tony... no disrespect intended and Im sure none taken... I think that you
missed my point and wasnt humble in doing so. If I was crude then I
apologize.. respectfully.
I thoroughly respect your contribution and knowledge to ISIS and MPLS.

Hey, BTW did anyone see the difference and/or detailed attention to the
security implications in that doc ?
Will

- I never knew why I should wanna catch flies

-----Original Message-----
From: Jeff Parker
To: 'Ferrell, William'; 'Tony Li '; Jeff Parker
Cc: 'ISIS-WG (E-mail) '
Sent: 4/8/03 2:05 PM
Subject: RE: [Isis-wg] RE: draft-ietf-isis-hmac-03.txt 

> From what you can tell thats the summ of my discussion ? 
> 
> This guy showed a deeper knowledge for operations as 
> well as the true security implications to include real 
> risk-mitigation. Which concretely conludes that he is 
> profoundly knowledgable of the technology.
>
> Will
> 
> > So you're suggesting that we trust source addresses?
> 
> > Tony
> 
> 
> |    -----Original Message-----
> |    From: Ferrell, William [mailto:[email-masked]] 
 
> |    I agree that there are many mitigation techniques the 
> |    simplest of course is to ACL with only trusted peers.  

Will -
	I can't speak for Tony, but suspect that this was the
comment he was responding to.  In the case of an IGP, the
peers are machines, and all we have to judge them by are
some bits in a packet.  As you know, those are easy to 
fake.  

	Currently, IS-IS is deployed in some important spots.
Any change to IS-IS that involves large changes is a non-
starter.  Thus security changes that involve major changes
in the protocol are out of the question.  We don't have 
the luxury of starting over.  

	You might get more traction if you start out with 
some specific suggestions.  These documents are not RFCs
yet, and improvement is always possible.  But suggesting
that the authors don't understand operations or security
isn't likely to get you very far.  

- jeff parker
- You can catch more flies with honey than with vinegar
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 8 Apr 2003 21:35:18 +0200

On Tue, Apr 08, 2003 at 02:53:27PM -0400, Ferrell, William wrote:
|  Jeff /T
| 
| Your right Jeff, absolutely right . Thats the troubles of my team...how to
| mitagte the faked bits etc. How to tust our peers, MD-5 over ISIS hasnt been
| standardized and the two major vendors have a slighty different
| implementations.(not that MD-5 is the greatest anyway)

william,

i hope that the implementations are different somehow ;-) -

last time i have looked we had all the knobs ready on both implementations
for full-scale interoperability [even on different understanding what PDUs
should be authenticated by default];

--

try to see it the other way around: by not including an explicit
crypto-seq-number what we have got is a simple uniform authentication
method across all PDU types; if we would have got the crypt-seq
number explicilty included in teh auth TLV then a whole set of
questions needs to be answered:

- do we need crypt-seq-numbers for LSPs ... most likely not
  as we already got the LSP sequence number ...

- do we need b/c of this differnt per-PDU auth TLVs ?

... you see there is some additional complexity involved here ...

if SPs are facing _real_ replay attacks on IIHs which may or
may not not [based on implementation] tear down an adjacency
then we can define a sequence number TLV to adress that issue
in the future; the open nature of the authentication TLV which
is build across the whole PDU does permit that;

/hannes

---

From: Alex Zinin <[email-masked]>
Date: Tue, 8 Apr 2003 15:12:09 -0700

Hannes, Ferrell-

<hat AD=off>

> is build across the whole PDU does permit that;

A while ago, I came to the WG with a proposal implementing the crypto
seq numbers and the key id for easier key transition, see
http://psg.com/~zinin/ietf/draft-zinin-isis-auth-anti-replay-00.txt

We had a discussion at a face-to-face meeting, and I think the main
objection was that the crypto seq number does not protect from replays
completely. In particular, when one of the routers on the segment goes
down, an attacker can successfully replay packets that it recorded.
This is possible because the neighbor's crypto state is maintained
together with the regular adjacency state and is removed once the
neighbor is lost. There was a proposal to look at whether a nonce can
be used to seed packet exchange with every new neighbor. The problem
could also be mitigated by retaining the state for lost neighbors
(e.g., in a Dead state) and checking the seq numbers when a new
adjacency with the router is established.

At that time there was clearly no agreement on what level of
protection in routing protocols is really needed (e.g., do we really
need replay protection given the nature of SP links in general, and
the properties of ISIS encapsulation in particular), and I got enough
of a push-back to drop the draft. On the other hand, we realized that
we need to bring routing and security people on the same page, so we
later started the RPSEC WG, which I think I should encourage Ferrell
to join.

Regards.

-- 
Alex
http://www.psg.com/~zinin/

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 09 Apr 2003 14:04:34 +0200

>later started the RPSEC WG, which I think I should encourage Ferrell
The push back to summarize again was:

either leave a half-backed '80% problem solved with 20% solved' thing 
(hmac today) in place
with the excuse that it was done and deployed quickly to solve real 
customer problems (which
in context of ISIS I'm perfectly fine with) OR sit down and spend 
serious amount of time to solve
authentication and privacy and integrity
in a single swoop so future generations don't split their sides laughing 
at an incompetent
effort. It can be done (look at PNNI security with the chain-of-trust, 
nonces and so on) but it is quite a lot
of work.

My opinion still stands

    thanks

        -- tony