Subject: Re: [karp] I-D ACTION:draft-ietf-karp-design-guide-01.txt

From: Sam Hartman <[email-masked]>
Date: Tue, 05 Oct 2010 09:00:05 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> I look forward to seeing what you have in the new draft.  I
    Jim> think that we really need to determine what security
    Jim> requirements we have on some of the protocols before we can
    Jim> rule in or out asymmetric signatures.

Can we please try and move that forward quickly?  I don't care much what
the answer is, but it potentially changes the entire approach.
I wonder if the chairs could help get input from the operator and router
implementors communities onthis.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 5 Oct 2010 08:58:45 -0700

So I guess the first question would be, are there any security issues for
the one-to-many or many-to-many protocols where people in the groups can lie
about who they are and there is no way to know the actual entity which
produced the routing.  I.e. a case where some entity gets adopted into the
routing group, later gets corrupted and starts lying about how the routing
should be done.

Jim

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Tuesday, October 05, 2010 6:00 AM
> To: Jim Schaad
> Cc: 'Sam Hartman'; [email-masked]
> Subject: Re: [karp] I-D ACTION:draft-ietf-karp-design-guide-01.txt
> 
the
> answer is, but it potentially changes the entire approach.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 05 Oct 2010 12:15:22 -0400

The current operating paradigm for OSPF and ISIS is that all the devices 
on a LAN share a single key.  As such, yes, any one of them can send a 
message claiming it is from any other one.
However, that actually does not do much to most of the protocol.  If 
router A forwards a set of advertisements from elsewhere, claiming that 
it is router B who is forwarding them, nothing actually gets broken. 
(And authenticating the content itself is out of scope for this working 
group.)

There is a vulnerability for sending fake hellos.  Unless we change the 
actual security mechanism in place however, a weak form of that 
vulnerability exists even if every router uses distinct keys for 
signing.  The only effect that can be found from this threat is that one 
could force reset the relationship between the routers.  But if an 
attacker does this, it will call immediate attention to the problem.  It 
is not clear that this is worth fixing.

We are working with some folks to demonstrate either that a separated 
key management can handle the multicast case, or that it can't.

Yours,
Joel

On 10/5/2010 11:58 AM, Jim Schaad wrote:
>>>>>>> "Jim" == Jim Schaad<[email-masked]>  writes:
>>
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: mark Brown <[email-masked]>
Date: Wed, 6 Oct 2010 05:30:18 +0530

Joel,

> The current operating paradigm for OSPF and ISIS is that all the devices on
> a LAN share a single key.  As such, yes, any one of them can send a message
> claiming it is from any other one.
> However, that actually does not do much to most of the protocol.  If router
> A forwards a set of advertisements from elsewhere, claiming that it is
> router B who is forwarding them, nothing actually gets broken. (And

I am not sure i understand this. If A forwards advertisements claiming
that its actually B thats forwarding them then wouldnt other routers
send traffic towards B, if those advertisements are the best ones? I
am not sure i understand why you dont think this breaks anything?

> authenticating the content itself is out of scope for this working group.)
>

And what is this vulnerability and why would it exist despite using
distinct keys?

Mark

> vulnerability exists even if every router uses distinct keys for signing.

>  The only effect that can be found from this threat is that one could force
> reset the relationship between the routers.  But if an attacker does this,
> it will call immediate attention to the problem.  It is not clear that this
> is worth fixing.
>
> We are working with some folks to demonstrate either that a separated key
> management can handle the multicast case, or that it can't.
>
> Yours,
> Joel
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 6 Oct 2010 09:18:14 +0530

Hi Mark,

> am not sure i understand why you dont think this breaks anything?

You can look at draft-ietf-opsec-routing-protocols-crypto-issues section 2.2 for more details.

The reason it will not break the advertisements in OSPF is because implementations look at the RouterID carried inside the LSA header to determine the neighbor. So, if A tries to send the same LSA that was originally sent by B, then receiving routers will process it as if it came from B, and will thus not affect routing. 

Cheers, Manav

> >> the one-to-many or many-to-many protocols where people in 
> the groups can
> >> lie