Subject: Re: [karp] [OSPF] Mechanism to protect OSPFv2 authentication from IP Layer Issues

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Oct 2010 11:25:19 -0400

I have three related concerns with this.
First, if I understand the drafts properly, the threat being addressed 
is that a rogue device on-link can reinject old hellos so as to disrupt 
established adjacencies on that link.  The attack affects only the link 
it is on, and causes visible and immediate effects.  It seems to me that 
if an attacker is present on enough links for this to be a problem, then 
one has a lot more issues than just the preservation of adjacencies.  In 
fact, using this attack calls immediate attention to the presence of the 
attacker.  (It is not like a remote DoS or DDoS where the attack can 
continue once the victim is aware.  network operators will be able to 
track this VERY fast.)

Second, how would this be deployed?  It requests a modification in the 
sender and receiver behavior for authentication.  Is your assumption 
that this would be handled like a key change?  First you upgrade every 
router on the LAN to be able to receive this, then you turn on sending 
it on the LAN?  It seems to me that in terms of diagnosing communication 
failures one needs to be able to tell from packet traces which behavior 
is actually being used.

The third question is actually the most important.  Given that operators 
would ahve to choose to enable this new behavior, is there any 
indication that they would do so?  I have heard reports that some 
operators have started turning off IGP authentication, or using it only 
as a stronger packet checksum.  In either case, this does not add value 
for those operators.

Yours,
Joel M. Halpern

On 10/11/2010 9:09 AM, Bhatia, Manav (Manav) wrote:
>
> Hi,
>
> Both draft-ietf-opsec-routing-protocols-crypto-issues-07.txt and draft-hartman-ospf-analysis-01.txt describe certain attacks that OSPFv2 is vulnerable to because of OSPFv2 not covering some fields from the IP header in its crypto computation. This draft describes a very simple mechanism to fix such auth vulnerabilities.
>
> Would be great if the WG members can go through this and provide some feedback.
>
> Cheers, Manav
>
> ----- Forwarded Message ----
> From: "[email-masked]"<[email-masked]>
> To: [email-masked]
> Sent: Mon, October 11, 2010 6:30:02 PM
> Subject: I-D Action:draft-bhatia-karp-ospf-ip-layer-protection-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>      Title          : Mechanism to protect OSPFv2 authentication from IP Layer Issues
>      Author(s)      : M. Bhatia
>      Filename        : draft-bhatia-karp-ospf-ip-layer-protection-00.txt
>      Pages          : 10
>      Date            : 2010-10-06
>
> The IP header is not covered by the MAC in the cryptographic
> authentication scheme as described in RFC 2328 and RFC 5709, and an
> attack can be made to exploit this omission.  This draft proposes a
> simple change in how the authentication is computed to eliminate most
> of such attacks.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bhatia-karp-ospf-ip-layer-protection-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 12 Oct 2010 04:23:21 +0530

Hi Joel,
 
[clipped]

> It seems 
> to me that 

Yup, I agree. However, it is a cheap solution to a vulnerability that exists and which has been mentioned in multiple documents.

This attack vector also appears to be in scope as per draft-ietf-karp-threats-reqs-01.txt (sec 2.1).

Additionally you could also look at the section 3 of the above document which says the following:

20.  In most routing protocols (OSPF, ISIS, BFD, RIP, etc), all
     speakers share the same key on a broadcast segment.  Possession
     of the key itself is used for identity validation and no other
     identity check is used.  This opens a window for an attack where
     the sender can masquerade as some other neighbor.  Routing
     protocols SHOULD thus use some other information besides the key
     to validate a neighbor.  One could look at
     [I-D.ietf-opsec-routing-protocols-crypto-issues] for details on
     such attacks.

21.  Routing protocols that rely on the IP header (or information
     beyond the routing protocol payload) to identify the neighbor
     which originated the packet must either protect the IP header or
     provide some other means to identify the neighbor.
     [I-D.ietf-opsec-routing-protocols-crypto-issues] describes some
     attacks that are based on this.

This solution attempts to fix the above mentioned issues. If we think that such attacks are NOT in scope of KARP then we need to remove them from the document lest folks spend time working on them.

> 
> Second, how would this be deployed?  It requests a 

This is an easy part and can be trivially taken care of once we decide that its indeed a problem that we need work on.

> modification in the 

We could define a new authentication type, say 3, which would indicate that the new mechanism (i.e. where Apad is not a constant but derived from source IP of the packet) is being used.

> as a stronger packet checksum.  In either case, this does not 

While I agree that some operators use authentication only for stronger checksum there are some that care for security. I also agree that its not very simple to launch these attacks, however, the idea behind this draft was as I had explained earlier - it fixes a potential issue at zero (implementation, computational and operational) cost that exists. My assumption was that if we are repeatedly citing a vulnerability then there is a willingness to fix it (see above).

Cheers, Manav

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 12 Oct 2010 13:21:32 -0400

If this has to be protected - I guess it's better to do the complete IP header (non-mutable) than only the SRC address.

Thanks,
Uma

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Monday, October 11, 2010 3:53 PM
To: Joel M. Halpern
Cc: [email-masked]; [email-masked]
Subject: Re: [karp] [OSPF] Mechanism to protect OSPFv2 authentication from IP Layer Issues

Hi Joel,
 
[clipped]

> It seems
> to me that
> if an attacker is present on enough links for this to be a problem, 
> then one has a lot more issues than just the preservation of 
> adjacencies.  In fact, using this attack calls immediate attention to 
> the presence of the attacker.  (It is not like a remote DoS or DDoS 
> where the attack can continue once the victim is aware.  network 
> operators will be able to track this VERY fast.)

> it on the LAN?  It seems to me that in terms of diagnosing 
> communication failures one needs to be able to tell from packet traces 
> which behavior is actually being used.

> 
> The third question is actually the most important.  Given that 
> operators would ahve to choose to enable this new behavior, is there 
> any indication that they would do so?  I have heard reports that some 
> operators have started turning off IGP authentication, or using it 
> only as a stronger packet checksum.  In either case, this does not add 
> value for those operators.

Cheers, Manav

_______________________________________________
karp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/karp

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 13 Oct 2010 06:33:17 +0530

Hi Uma,

The reason I did just the source address was because that is the only vulnerability identified till date and is extremely simple to implement with no operational/computational overhead.

However, if the WG thinks that it makes sense for us to cover all the nonmutable fields of the IP header, then that too can be done.

Cheers, Manav  

> From: Uma Chunduri [mailto:[email-masked]] 
> Sent: Tuesday, October 12, 2010 10.52 PM
> To: Bhatia, Manav (Manav); Joel M. Halpern
> Subject: RE: [karp] [OSPF] Mechanism to protect OSPFv2 
> authentication from IP Layer Issues
> 
> If this has to be protected - I guess it's better to do the 
> complete IP header (non-mutable) than only the SRC address.
> 
> Thanks,
> Uma
> 
> 
> 
> Yup, I agree. However, it is a cheap solution to a 
> vulnerability that exists and which has been mentioned in 
> multiple documents.
> 
> This attack vector also appears to be in scope as per 
> draft-ietf-karp-threats-reqs-01.txt (sec 2.1).
> 
> This solution attempts to fix the above mentioned issues. If 
> we think that such attacks are NOT in scope of KARP then we 
> need to remove them from the document lest folks spend time 
> working on them.
> 
> > 
> This is an easy part and can be trivially taken care of once 
> we decide that its indeed a problem that we need work on.
> 
> > modification in the
> We could define a new authentication type, say 3, which would 
> indicate that the new mechanism (i.e. where Apad is not a 
> constant but derived from source IP of the packet) is being used.
> 
> > 
> While I agree that some operators use authentication only for 
> stronger checksum there are some that care for security. I 
> also agree that its not very simple to launch these attacks, 
> however, the idea behind this draft was as I had explained 
> earlier - it fixes a potential issue at zero (implementation, 
> computational and operational) cost that exists. My 
> assumption was that if we are repeatedly citing a 
> vulnerability then there is a willingness to fix it (see above).
> 
> Cheers, Manav
>

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 12 Oct 2010 21:49:43 -0400

>>The reason I did just the source address was because that is the only vulnerability identified till date and is extremely simple to implement with no operational/computational overhead.

**IF** MitM can happen and some body can change the SRC address- it's quite simple to make the receiver drop OSPF packet by changing other fields of the IP header.
I definitely feel it's better to protect complete IP header if at all it's attempted. One way could be with the new Autype - calculate message digest on IPHeader(nonmutable)+OSPF+etc..(RFC 2328 - D.4.3 6(c)).

Thanks,
Uma

> Subject: RE: [karp] [OSPF] Mechanism to protect OSPFv2 authentication 
> from IP Layer Issues
> 
> If this has to be protected - I guess it's better to do the complete 
> IP header (non-mutable) than only the SRC address.
> 
> Thanks,
> Uma
> 
> 
> 
> Yup, I agree. However, it is a cheap solution to a vulnerability that 
> exists and which has been mentioned in multiple documents.
> 
> This solution attempts to fix the above mentioned issues. If we think 
> that such attacks are NOT in scope of KARP then we need to remove them 
> from the document lest folks spend time working on them.
> 
> > 
> This is an easy part and can be trivially taken care of once we decide 
> that its indeed a problem that we need work on.
> 
> > modification in the
> We could define a new authentication type, say 3, which would indicate 
> that the new mechanism (i.e. where Apad is not a constant but derived 
> from source IP of the packet) is being used.
> 
> > 
> While I agree that some operators use authentication only for stronger 
> checksum there are some that care for security. I also agree that its 
> not very simple to launch these attacks, however, the idea behind this 
> draft was as I had explained earlier - it fixes a potential issue at 
> zero (implementation, computational and operational) cost that exists. 
> My assumption was that if we are repeatedly citing a vulnerability 
> then there is a willingness to fix it (see above).
> 
> Cheers, Manav
>

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 12 Oct 2010 19:45:04 -0700

Hi,

I find this interesting. If a packet is modified so that it is dropped
it could very well be dropped by the router itself.

Thanks,
Vishwas

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 13 Oct 2010 18:58:28 +0530

Hi Joel,

> as a stronger packet checksum.  In either case, this does not 

http://www.ietf.org/id/draft-jakma-ospf-integrity-00.txt should work for operators who are only turning on OSPF authentication as a substitute for a stronger packet checksum.

I had posted a survey on nanog (we had also exchanged a mail on this) on the same and while I only got 7 responses, 4 of those stated that they were indeed using IGP crypto only to get a better checksum mechanism. 

Cheers, Manav

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 13 Oct 2010 09:57:14 -0400

draft-ietf-karp-threats-reqs-01.txt (sec 2.1) on-path/in scope attack-actions 

- how much it's real and applicable for RPs?
- LAN: is replay a possibility with changed SRC

Thanks,
Uma

-----Original Message-----
From: Vishwas Manral [mailto:[email-masked]] 
Sent: Tuesday, October 12, 2010 7:45 PM
To: Uma Chunduri
Cc: Bhatia, Manav (Manav); Joel M. Halpern; [email-masked]; [email-masked]
Subject: Re: [karp] [OSPF] Mechanism to protect OSPFv2 authentication from IP Layer Issues

Hi,

I find this interesting. If a packet is modified so that it is dropped it could very well be dropped by the router itself.

Thanks,
Vishwas

On Tue, Oct 12, 2010 at 6:49 PM, Uma Chunduri <[email-masked]> wrote:
>> that such attacks are NOT in scope of KARP then we need to remove 
>> them from the document lest folks spend time working on them.
>>
>> >
>> This is an easy part and can be trivially taken care of once we 
>> decide that its indeed a problem that we need work on.
>>
>> > modification in the
>> indicate that the new mechanism (i.e. where Apad is not a constant 
>> but derived from source IP of the packet) is being used.
>>
>> >
>> stronger checksum there are some that care for security. I also agree 
>> that its not very simple to launch these attacks, however, the idea 
>> behind this draft was as I had explained earlier - it fixes a 
>> potential issue at zero (implementation, computational and operational) cost that exists.

---

From: Venkatesh Sriram <[email-masked]>
Date: Wed, 13 Oct 2010 22:22:43 +0530

Given that KARP is about how to secure packets on the wire i would
wager that it should be in scope. Theoretically, replay with a changed
SRC is possible. Also, we should bear in mind that what may not be
possible today may become possible in the coming future. Thus i dont
see any harm in a taking a preemptive step that protects us against
such attacks.

Sriram

---

From: mark Brown <[email-masked]>
Date: Sat, 16 Oct 2010 02:00:01 +0530

+1

---

From: mark Brown <[email-masked]>
Date: Sat, 16 Oct 2010 02:12:48 +0530

> I had posted a survey on nanog (we had also exchanged a mail on this) on the same and while I only got 7 responses, 4 of those stated that they were indeed using IGP crypto only to get a better che…

This is interesting.

Are there any folks in these mailing lists who use, or who know folks
that use, cryptographic authentication as a substitute for the
internet checksum that OSPF currently uses?

Mark

---

From: Glen Kent <[email-masked]>
Date: Sat, 16 Oct 2010 07:23:56 +0530

Mark,

>> I had posted a survey on nanog (we had also exchanged a mail on this) on the same and while I only got 7 responses, 4 of those stated that they were indeed using IGP crypto only to get a better ch…

Yes, it indeed is.

> internet checksum that OSPF currently uses?

None of the operators would be willing to disclose their security
policies, so you will most likely never receive a response to such a
query in public. You might get a few responses offline if you are
lucky, but thats about it.

Coming back to your question - Yes, i would wager that there might be
a few that do this for precisely the reasons described in the original
document.

Glen

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 15 Oct 2010 19:38:27 -0700

Joel's widget number 2

> lucky, but thats about it.

Hi, I'm an operator...

And I use ospf cryptographic authentication to preclude the accidental introduction of new router's in datacenter environments. Just because two devices are connected to the same broadcast domain does not mean they should form an adjacency.

> a few that do this Sfor precisely the reasons described in the original
> document.
> 
> Glen

---

From: Glen Kent <[email-masked]>
Date: Sat, 16 Oct 2010 10:50:44 +0530

Hi Joel,

> And I use ospf cryptographic authentication to preclude the accidental introduction of new router's in datacenter environments. Just because two devices are connected to the same broadcast domain d…

Why dont you use cleartext for that? This would avoid "accidental"
adjacency formation between two unrelated routers on the same lan,
unless one of them actively snoops the packets from the other, and
tries forming an adjacency with that router.

I see one advantage in using crypto - In data center environments most
folks can see packets from others since they share the same bcast
domain. In such cases, somebody can bring up a session with a
different OSPF router if there is no auth or cleartext used. This cant
be done with crypto though. Somebody can also launch attacks on the
other.

Is this the reason for using crypto auth?

Glen

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 17 Oct 2010 23:15:06 -0700

> tries forming an adjacency with that router.

I'm not sure I'd presuppose that. In addition to a natural aversion to
clear-text passwords which frankly I think is sensible, the password
field 64 bits in length, which is not a large password, the password
input for the message digests on the other hand, have no such limitation.