Subject: [karp] Please take a look at draft-hartman-karp-ospf-analysis

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Jun 2010 13:52:34 -0400

Dacheng Zhang and I have been trying to put together a skeleton of what
we think is required as the first phase of the design team work for
OSPF.  We've reached a point where we'd like to get comments from the WG
and where we'd like to ask the OSPF design team to consider this input
once it is organized.

This work is heavily influenced by the OPSEC vulnerabilities analysis
document which covers all the routing protocols and by an earlier RPSEC
document specific to OSPF.  However, we've tried to focus specifically
on the KARP context.  One area where we think the OSPF design team will
need to go beyond the existing analysis is in looking at replay
protection and replay vulnerabilities.
There are a number of mechanisms within OSPF that interact and
understanding the impact of replays on OSPF is tricky.
We've taken a first stab at that, taking the previous work as a starting
point.

Also, we've taken a first stab at requirements and gap analysis.

We'd appreciate your comments.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 18 Jun 2010 04:49:22 +0530

Hi Sam,

Thanks for the first stab! I have been meaning to do it since a long time but never got around doing it. I have briefly gone through the draft and I think we also need to address the following points:

o We must provide both intra and inter-connection replay protection mechanisms. In case of latter, attackers must not be able to replay packets captured from an old session to a new session. This is currently the biggest vulnerability in OSPF as we cannot disambiguate packets from one session with the other.

o Most routing protocol implementations prioritize some specific packets. This could be the HELLOs and the ACKs in case of OSPF. Current replay protection mechanism as described in RFC2328 breaks this. There are implementation hacks to get around it, however, this is a gap that needs to be filled.

o Intra connection re-keying is currently not possible in OSPF. One could in theory do it as long as all routers in the domain change the key within the RouterDeadInterval time. However this is easier said than done, and the design team should consider this too.

Cheers, Manav

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sam Hartman
> Sent: Thursday, June 17, 2010 11.23 PM
> To: [email-masked]
> Subject: [karp] Please take a look at draft-hartman-karp-ospf-analysis
> 
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: mark Brown <[email-masked]>
Date: Fri, 18 Jun 2010 10:09:12 +0530

Your draft seems to suggest that OSPFv3 does not use any replay
protection at all. Is this true? If OSPFv3 is using ESP, then what
about the sequence number thats carried inside the ESP-NULL header?

I understand that we are using manual keying here, and the sequence
number isnt mandatory, however, the same is the case with OSPFv2. If
we can use the sequence numbers with OSPFv2, which has been manually
keyed just like v3, then why cant we do it for OSPFv3?

Mark

---

From: Dacheng Zhang <[email-masked]>
Date: Fri, 18 Jun 2010 14:33:33 +0800

Hi, 

I don’t think we try to argue  that there should be no replay protection provided in OSPFv3. In contrast, we believe the replay protection is critical and is a big benefit brought by automatic key management mechanisms. 

In section 3.2, we just attempt to briefly introduce the work proposed in RFC 4552. 

There is a statement in RFC4552: 

“Since it is not possible using the current standards to provide complete replay protection while using manual keying, the proposed solution will not provide protection against replay attacks.” 

We agree with this argument and mention it in our draft.

Thanks a lot for your comments.

Dacheng

张大成
华为技术有限公司  huawei_logo

地址：华为北京研究所，上地信息路甲九号
http://www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 
> mark Brown
> 发送时间: 2010年6月18日 12:39
> 收件人: Sam Hartman; [email-masked]
> 主题: Re: [karp] Please take a look at draft-hartman-karp-ospf-analysis
> 
> Your draft seems to suggest that OSPFv3 does not use any 
> replay protection at all. Is this true? If OSPFv3 is using 
> ESP, then what about the sequence number thats carried inside 
> the ESP-NULL header?
> 
> I understand that we are using manual keying here, and the 
> sequence number isnt mandatory, however, the same is the case 
> with OSPFv2. If we can use the sequence numbers with OSPFv2, 
> which has been manually keyed just like v3, then why cant we 
> do it for OSPFv3?
> 
> Mark
> 
> > Dacheng Zhang and I have been trying to put together a skeleton of 
> > what we think is required as the first phase of the design 
> team work 
> > for OSPF.  We've reached a point where we'd like to get 
> comments from 
> > the WG and where we'd like to ask the OSPF design team to consider 
> > this input once it is organized.
> >
> > document which covers all the routing protocols and by an earlier 
> > RPSEC document specific to OSPF.  However, we've tried to focus 
> > specifically on the KARP context.  One area where we think the OSPF 
> > design team will need to go beyond the existing analysis is 
> in looking 
> > at replay protection and replay vulnerabilities.
> > We've taken a first stab at that, taking the previous work as a 
> > starting point.
> >

---

From: Sam Hartman <[email-masked]>
Date: Fri, 18 Jun 2010 09:00:17 -0400

>>>>> "Bhatia," == Bhatia, Manav (Manav) <[email-masked]> writes:

    Bhatia,> o We must provide both intra and inter-connection replay
    Bhatia,> protection mechanisms. In case of latter, attackers must
    Bhatia,> not be able to replay packets captured from an old session
    Bhatia,> to a new session. This is currently the biggest
    Bhatia,> vulnerability in OSPF as we cannot disambiguate packets
    Bhatia,> from one session with the other.

Well, today, OSPF doesn't even have the concept of a session.  I think
what you're trying to say in the terminology of today's OSPF is that I
can potentially replay a packet from a time in the past where my
sequence number space overlapped with or is greater than my current
sequence number space and create a really big DOS until the adjacency
goes away.

I'm not sure I agree this is the biggest vulnerability: there seem to be
several attacks that fall into this category.

    Bhatia,> o Most routing protocol implementations prioritize some
    Bhatia,> specific packets. This could be the HELLOs and the ACKs in
    Bhatia,> case of OSPF. Current replay protection mechanism as
    Bhatia,> described in RFC2328 breaks this. There are implementation
    Bhatia,> hacks to get around it, however, this is a gap that needs
    Bhatia,> to be filled.

Explain how the replay mechanism breaks this; that's not obvious to me.

    Bhatia,> o Intra connection re-keying is currently not possible in
    Bhatia,> OSPF. One could in theory do it as long as all routers in
    Bhatia,> the domain change the key within the RouterDeadInterval
    Bhatia,> time. However this is easier said than done, and the design
    Bhatia,> team should consider this too.

I don't understand what you mean by intra-connection re-keying.  Do you
mean that if I want to change the key *now* that I'm in kind of bind
because there is not separate use-for-send lifetimes vs use-for-receive
lifetimes?
Or is it something more complicated?

---

From: Sam Hartman <[email-masked]>
Date: Fri, 18 Jun 2010 13:07:27 -0400

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

>     Bhatia,> o Most routing protocol implementations prioritize
> some Bhatia,> specific packets. This could be the HELLOs and
> the ACKs in Bhatia,> case of OSPF. Current replay protection
> mechanism as Bhatia,> described in RFC2328 breaks this. There
> are implementation Bhatia,> hacks to get around it, however,
> this is a gap that needs Bhatia,> to be filled.

    Sam> Explain how the replay mechanism breaks this; that's not
    Sam> obvious to me.

Is it that if I process packets out of order and only maintain one
sequence number,  then I'll discard the packets I skipped later?

---

From: Sam Hartman <[email-masked]>
Date: Fri, 18 Jun 2010 14:32:22 -0400

>>>>> "mark" == mark Brown <[email-masked]> writes:

    mark> Your draft seems to suggest that OSPFv3 does not use any
    mark> replay protection at all. Is this true? If OSPFv3 is using
    mark> ESP, then what about the sequence number thats carried inside
    mark> the ESP-NULL header?

    mark> I understand that we are using manual keying here, and the
    mark> sequence number isnt mandatory, however, the same is the case
    mark> with OSPFv2. If we can use the sequence numbers with OSPFv2,
    mark> which has been manually keyed just like v3, then why cant we
    mark> do it for OSPFv3?

IPsec has a sliding window for replay protection.  When you set up the
SA, you need to know what sequence numbers to expect from a peer.
I don't understand how this is possible for manual keying as deployed in
OSPFv3.

At a technical level you could initialize the sequence number from the
first packet you see.  I have fairly high confidence you could not get
that standardized by the IPsec community in a manner that would be
useful for OSPF.

There is a sequence number in an ESP packet.  However by using IPsec,
you choose IPsec semantics.  Those semantics are not aligned with your
requirements.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 19 Jun 2010 06:23:37 +0530

> sequence number space and create a really big DOS until the adjacency

Yes, that's precisely what I mean. Which is why I wanted an inter-connection replay protection mechanism. If we can somehow embed some information/state about the current session in the protocol packets then we can avoid these attacks despite reusing the key for multiple sessions.

> Explain how the replay mechanism breaks this; that's not 

Router A sends DD with crypto seq number X and HELLO with X+n. On the receiving side, since the HELLOs have been prioritized, it receives and processes the HELLO before the other protocol packets. It sees the current crypto sequence number as X+n and moves its current crypto sequence number pointer to X+n and rejects all packets with sequence numbers less than X+n.

Even if implementations implement an IPSec like sliding window for the sequence numbers, we could still get into a state where the window moves past a low priority packet's crypto seq number.

Currently implementations employ various hacks to get around this.

> Or is it something more complicated?

By intra connection rekeying I had meant changing the authentication keys once all the sessions are up, without bouncing the adjacencies. OSPF uses the KeyID that it receives in the protocol packets for authentication. If it does not find that Key ID or if that Key ID does not yield the right result then it will drop the protocol packets. So, for rekeying the admin needs to do the following within the RouterDeadInterval:

o Move to new Key ID that maps to a different security parameters.

OR

o Associate a different key/security parameters with the existing Key ID

However, this has to be done before the RouterDeadInterval on *all* links as otherwise OSPF will flap. This becomes extremely complicated and onerous with routers having lower RouterDeadIntervals.

One workaround and a possible input to the design team could be to have a set of acceptable Key IDs that OSPF on the receiving side could use in case the Key ID in the incoming packet isn't the active one.

Cheers, Manav

---

From: Sam Hartman <[email-masked]>
Date: Tue, 22 Jun 2010 15:43:44 -0400

I believe That we've described the issues surrounding prioritization for
OSPFv2 and inter-connection replay for an upcoming 01 version of the
draft that we'll hope to have out in a couple of days.  Thanks again for
your comments.