Subject: [OPSEC] Some comments/disussion points on draft-ietf-opsec-routing-protocols-crypto-issues-05

From: "Sonalker, Anuja" <[email-masked]>
Date: Mon, 7 Jun 2010 11:44:07 -0400

Dear Authors,

First of all, I would like to say what a great initiative this has been
to document all cryptographic security issues with routing protocols.
This document can become a great source of information for implementers,
operators, researchers, engineers, device manufacturers, and others
alike. In the interest of making this document finer, I had a few
suggestions for the authors to review. Hopefully, they will be of
benefit to you.

Thanks,

Anuja

Few comments on the opsec-routing-protocols-crypto-issues-05 IETF draft 

1)      Confidentiality as an issue in the Problem Statement 

The document aptly notes that digest verification mechanisms are not
intended to provide confidentiality, and that one router's routing table
information could possibly be exposed to other routers in many different
ways. Since confidentiality is not a critical issue for all routing
protocols in general, it would be beneficial to highlight and
acknowledge the same. For example, while confidentiality is of critical
interest to inter autonomous system protocols like BGP, or ones where
business relationships may be under threat of exposure, it is of not as
much (critical) concern to IGPs like OSPF. 

2)      OSPFv2  Management issues section possible clashing ideas. The
first two paragraphs indicate that OSPF uses MD5 and that there neither
exists a mechanism to negotiate keys, nor to negotiate the hash
algorithms to be used. However, the paragraph immediately following it
talks about the proliferation of a number of hash algorithms, as well as
the need to continuously upgrade the algorithms with the problems this
would face in OSPF. This statement seems more applicable to RFC5709
rather than the OSPF base algorithm itself and should probably accompany
a much later paragraph [Section 2.2, Paragraph 5].  A similar issue
exists for IS-IS. Both these sections would benefit from a reference to
karp, another IETF initiative that deals with solutions for
cryptographic authentication and key management for routing protocols.
Referencing and acknowledging other active work that is trying to
mitigate routing security cryptographic issues would complement this
section very well, and provide readers and implementers a more complete
picture of the problem and what it would take to solve it. 

3)      DoS attacks as crypto issues, and applicability. While the
presence and or use of cryptographic functions at the victim end does
allow the attacker to have a greater impact on the victim with lesser
effort, DoS attacks can, in reality, be launched on any network even in
the absence of cryptographic functions. (e.g., tcp syn flooding, etc).
Therefore, in a way, cryptographic performance demands can facilitate
DoS attacks. This is noteworthy. However, careful implementation choices
lessen the impact of cryptographic performance demands on the recipient
end, thereby resulting in wasted effort at the attacker end, making the
DoS attack less lucrative to launch. This should probably be indicated.
Secondly, this attack is discussed selectively only under a few routing
protocols in the document when it is clearly applicable to almost all.  

4)      BGP v4 Management issues. "Most BGP implementations will accept
BGP packets with a bad digest up to the hold interval negotiated between
BGP peers at peering startup." The authors have highlighted an issue
that is specific to certain implementations. Since this is an
implementation detail, the motivation behind this choice should be noted
in order for the readers to fully understand the compelling reasons
behind making such a choice. Secondly, if implementation specific issues
are to be considered within scope of this document then, for
consistency, the same should be considered of all known and currently in
use implementations of all routing protocols that fall within the scope
of this initiative. This would result in a long and drawn out process of
accumulating such information. Thirdly, as implementations get updated
these issues would cease to be relevant issues. Finally, since the karp
initiative deals with these kinds of problems it would be very
informative to mention the initiative here. 

5)      RIPv2 replay same seq# attack. Since a repeated sequence number
is detected as a replay, and discarded, what impact does this attack
have on the recipient? What damage results from this attack to the
routing?

6)      The current abstract only talks about certain cryptographic
digests that have been made obsolete due to recent findings while the
document deals with other relevant issues as well. Therefore, the
abstract should be updated to indicate the full content of document.  

7)      The authors should include, wherever relevant, references to
other initiatives like karp that have intersections with the content
that the opsec-crypto-issues draft addresses. This will facilitate
better interactions across various working groups, and provide
implementers, and operators a greater awareness and a more complete
picture of routing security and cryptography issues.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 8 Jun 2010 05:06:24 +0530

Hi Anuja,

Thanks for the comments. We will definitely consider them when updating the document.

Regarding your point (5) about RIPv2 .

The doc clearly states that the attack is only possible *if* somebody is able to capture a higher cryptographic sequence number (possibly before the seq number space rolled over or router rebooted, etc) packet from the source. That packet can be replayed to disrupt routing as explained in the document.

More inline ..

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sonalker, Anuja
Sent: Monday, June 07, 2010 9.14 PM
To: [email-masked]
Subject: [OPSEC] Some comments/disussion points on draft-ietf-opsec-routing-protocols-crypto-issues-05

Dear Authors,

First of all, I would like to say what a great initiative this has been to document all cryptographic security issues with routing protocols. This document can become a great source of information for implementers, operators, researchers, engineers, device manufacturers, and others alike. In the interest of making this document finer, I had a few suggestions for the authors to review. Hopefully, they will be of benefit to you.

Thanks,
Anuja

The document aptly notes that digest verification mechanisms are not intended to provide confidentiality, and that one router's routing table information could possibly be exposed to other routers in many different ways. Since confidentiality is not a critical issue for all routing protocols in general, it would be beneficial to highlight and acknowledge the same. For example, while confidentiality is of critical interest to inter autonomous system protocols like BGP, or ones where business relationships may be under threat of exposure, it is of not as much (critical) concern to IGPs like OSPF.

2)      OSPFv2  Management issues section possible clashing ideas. The first two paragraphs indicate that OSPF uses MD5 and that there neither exists a mechanism to negotiate keys, nor to negotiate the hash algorithms to be used. However, the paragraph immediately following it talks about the proliferation of a number of hash algorithms, as well as the need to continuously upgrade the algorithms with the problems this would face in OSPF. This statement seems more applicable to RFC5709 rather than the OSPF base algorithm itself and should probably accompany a much later

<Manav> I am not sure i understand this. Why is this more applicable for 5709?

Cheers, Manav

 paragraph [Section 2.2, Paragraph 5].  A similar issue exists for IS-IS. Both these sections would benefit from a reference to karp, another IETF initiative that deals with solutions for cryptographic authentication and key management for routing protocols. Referencing and acknowledging other active work that is trying to mitigate routing security cryptographic issues would complement this section very well, and provide readers and implementers a more complete picture of the problem and what it would take to solve it.

3)      DoS attacks as crypto issues, and applicability. While the presence and or use of cryptographic functions at the victim end does allow the attacker to have a greater impact on the victim with lesser effort, DoS attacks can, in reality, be launched on any network even in the absence of cryptographic functions. (e.g., tcp syn flooding, etc). Therefore, in a way, cryptographic performance demands can facilitate DoS attacks. This is noteworthy. However, careful implementation choices lessen the impact of cryptographic performance demands on the recipient end, thereby resulting in wasted effort at the attacker end, making the DoS attack less lucrative to launch. This should probably be indicated.  Secondly, this attack is discussed selectively only under a few routing protocols in the document when it is clearly applicable to almost all.

4)      BGP v4 Management issues. "Most BGP implementations will accept BGP packets with a bad digest up to the hold interval negotiated between BGP peers at peering startup." The authors have highlighted an issue that is specific to certain implementations. Since this is an implementation detail, the motivation behind this choice should be noted in order for the readers to fully understand the compelling reasons behind making such a choice. Secondly, if implementation specific issues are to be considered within scope of this document then, for consistency, the same should be considered of all known and currently in use implementations of all routing protocols that fall within the scope of this initiative. This would result in a long and drawn out process of accumulating such information. Thirdly, as implementations get updated these issues would cease to be relevant issues. Finally, since the karp initiative deals with these kinds of problems it would be very informative to mention the initiative here.

5)      RIPv2 replay same seq# attack. Since a repeated sequence number is detected as a replay, and discarded, what impact does this attack have on the recipient? What damage results from this attack to the routing?

6)      The current abstract only talks about certain cryptographic digests that have been made obsolete due to recent findings while the document deals with other relevant issues as well. Therefore, the abstract should be updated to indicate the full content of document.

7)      The authors should include, wherever relevant, references to other initiatives like karp that have intersections with the content that the opsec-crypto-issues draft addresses. This will facilitate better interactions across various working groups, and provide implementers, and operators a greater awareness and a more complete picture of routing security and cryptography issues.

---

From: "Sonalker, Anuja" <[email-masked]>
Date: Thu, 10 Jun 2010 17:46:58 -0400

Manav,

Thanks for your response. Sorry for the delay in responding back.  Let
me try to clarify further. 

<Manav> I am not sure i understand this. Why is this more applicable for
5709?

Ospfv2 base spec does not have the provision to negotiate any hash
algorithms.  5709 adds support for using various other algorithms (
SHA-family, HMAC mode). So the statement about the proliferation of hash
algorithms and need for update mechanisms seems more applicable to 5709
as opposed to 2328. <imho>

<Manav> Regarding your point (5) about RIPv2 .

The doc clearly states that the attack is only possible *if* somebody is
able to capture a higher cryptographic sequence number (possibly before
the seq number space rolled over or router rebooted, etc) packet from
the source. That packet can be replayed to disrupt routing as explained
in the document.

Sounds like we are talking about different issues. Yes, the attack you
describe in Scenario 1 does require a higher sequence number (and is
clearly stated.) ...but I was talking about the bulleted paragraph under
Section 6.1 (page 12, second  bullet) --   "RIPv2 allows multiple
packets with the *same* sequence number. This could mean the same packet
may be replayed many times before the next legitimate packet is sent. An
attacker may resend the same packet repeatedly until the next Hello
packet is transmitted and received, which means the hello interval
therefore determines the attack window." This sounds like  a slightly
different attack than the higher sequence number attack you describe in
Scenario 1 which executed by replaying any packet from the LAN with a
*higher* sequence number, and possibly changing the originator IP
information. 

With a higher sequence number coming from the attacker, R1 is now unable
to send legitimate routing updates anymore --as you have stated. This is
perfectly true. The question is - if the *same* sequence number packet
is replayed by the attacker, what effect would that have on R1?  What
effect would that have on the network?

Hope my question is clearer now. 

Thanks so much!

-Anuja

 

From: Bhatia, Manav (Manav) [mailto:[email-masked]] 
Sent: Monday, June 07, 2010 7:36 PM
To: Sonalker, Anuja; [email-masked]
Subject: RE: [OPSEC] Some comments/disussion points
ondraft-ietf-opsec-routing-protocols-crypto-issues-05

Hi Anuja,

Thanks for the comments. We will definitely consider them when updating
the document.

The doc clearly states that the attack is only possible *if* somebody is
able to capture a higher cryptographic sequence number (possibly before
the seq number space rolled over or router rebooted, etc) packet from
the source. That packet can be replayed to disrupt routing as explained
in the document.

More inline ..

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sonalker, Anuja
Sent: Monday, June 07, 2010 9.14 PM
To: [email-masked]
Subject: [OPSEC] Some comments/disussion points on
draft-ietf-opsec-routing-protocols-crypto-issues-05

	Dear Authors,

	First of all, I would like to say what a great initiative this
has been to document all cryptographic security issues with routing
protocols. This document can become a great source of information for
implementers, operators, researchers, engineers, device manufacturers,
and others alike. In the interest of making this document finer, I had a
few suggestions for the authors to review. Hopefully, they will be of
benefit to you.

	Thanks,

	Anuja

	Few comments on the opsec-routing-protocols-crypto-issues-05
IETF draft 

	The document aptly notes that digest verification mechanisms are
not intended to provide confidentiality, and that one router's routing
table information could possibly be exposed to other routers in many
different ways. Since confidentiality is not a critical issue for all
routing protocols in general, it would be beneficial to highlight and
acknowledge the same. For example, while confidentiality is of critical
interest to inter autonomous system protocols like BGP, or ones where
business relationships may be under threat of exposure, it is of not as
much (critical) concern to IGPs like OSPF. 

	2)      OSPFv2  Management issues section possible clashing
ideas. The first two paragraphs indicate that OSPF uses MD5 and that
there neither exists a mechanism to negotiate keys, nor to negotiate the
hash algorithms to be used. However, the paragraph immediately following
it talks about the proliferation of a number of hash algorithms, as well
as the need to continuously upgrade the algorithms with the problems
this would face in OSPF. This statement seems more applicable to RFC5709
rather than the OSPF base algorithm itself and should probably accompany
a much later  

	<Manav> I am not sure i understand this. Why is this more
applicable for 5709?

	Cheers, Manav

	 paragraph [Section 2.2, Paragraph 5].  A similar issue exists
for IS-IS. Both these sections would benefit from a reference to karp,
another IETF initiative that deals with solutions for cryptographic
authentication and key management for routing protocols. Referencing and
acknowledging other active work that is trying to mitigate routing
security cryptographic issues would complement this section very well,
and provide readers and implementers a more complete picture of the
problem and what it would take to solve it.  

	3)      DoS attacks as crypto issues, and applicability. While
the presence and or use of cryptographic functions at the victim end
does allow the attacker to have a greater impact on the victim with
lesser effort, DoS attacks can, in reality, be launched on any network
even in the absence of cryptographic functions. (e.g., tcp syn flooding,
etc). Therefore, in a way, cryptographic performance demands can
facilitate DoS attacks. This is noteworthy. However, careful
implementation choices lessen the impact of cryptographic performance
demands on the recipient end, thereby resulting in wasted effort at the
attacker end, making the DoS attack less lucrative to launch. This
should probably be indicated.  Secondly, this attack is discussed
selectively only under a few routing protocols in the document when it
is clearly applicable to almost all.  

	4)      BGP v4 Management issues. "Most BGP implementations will
accept BGP packets with a bad digest up to the hold interval negotiated
between BGP peers at peering startup." The authors have highlighted an
issue that is specific to certain implementations. Since this is an
implementation detail, the motivation behind this choice should be noted
in order for the readers to fully understand the compelling reasons
behind making such a choice. Secondly, if implementation specific issues
are to be considered within scope of this document then, for
consistency, the same should be considered of all known and currently in
use implementations of all routing protocols that fall within the scope
of this initiative. This would result in a long and drawn out process of
accumulating such information. Thirdly, as implementations get updated
these issues would cease to be relevant issues. Finally, since the karp
initiative deals with these kinds of problems it would be very
informative to mention the initiative here. 

	5)      RIPv2 replay same seq# attack. Since a repeated sequence
number is detected as a replay, and discarded, what impact does this
attack have on the recipient? What damage results from this attack to
the routing?

	6)      The current abstract only talks about certain
cryptographic digests that have been made obsolete due to recent
findings while the document deals with other relevant issues as well.
Therefore, the abstract should be updated to indicate the full content
of document.  

	7)      The authors should include, wherever relevant,
references to other initiatives like karp that have intersections with
the content that the opsec-crypto-issues draft addresses. This will
facilitate better interactions across various working groups, and
provide implementers, and operators a greater awareness and a more
complete picture of routing security and cryptography issues.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 15 Jun 2010 13:33:59 +0530

Hi Anuja,
 
> Ospfv2 base spec does not have the provision to negotiate 
> any hash algorithms.  5709 adds support for using various 
> other algorithms ( SHA-family, HMAC mode). So the statement
> about the proliferation of hash algorithms and need for 
> update mechanisms seems more applicable to 5709 as opposed to 2328. <imho> 

I am still unclear about this.

If you look at the original text it says the following:

"OSPF does not specify a mechanism to negotiate keys, nor does it 
specify any mechanism to negotiate the hash algorithms to be used."

This remains true even with 5709. 5709 really adds nothing new to the base spec in terms of negotiating keys, exchanging the hash algo information, etc. The only thing it does is to explain the semantics of how the HMAC-SHA-X computation must be done.

[clipped]

> Sounds like we are talking about different issues. Yes, the 
> attack you describe in Scenario 1 does require a higher 
> sequence number (and is clearly stated.) ...but I was talking
> about the bulleted paragraph under Section 6.1 (page 12, second 
> bullet) --   "RIPv2 allows multiple packets with the *same* 
> sequence number. This could mean the same packet may be replayed
>  many times before the next legitimate packet is sent. An attacker 
> may resend the same packet repeatedly until the next Hello packet
>  is transmitted and received, which means the hello interval
>  therefore determines the attack window." This sounds like  a
>  slightly different attack than the higher sequence number attack 
> you describe in Scenario 1 which executed by replaying any packet 
> from the LAN with a  *higher* sequence number, and possibly 
> changing the originator IP information. 

> With a higher sequence number coming from the attacker, 
> R1 is now unable to send legitimate routing updates anymore 
> --as you have stated. This is perfectly true. The question is - 
> if the *same* sequence number packet is replayed by the attacker,
> what effect would that have on R1?  What effect would that have on the network?

It can disrupt the routing. If you replay a packet with the same sequence number from an earlier session then this would be accepted, as RIP would accept packets with the same seq number. 

Hope this helps.

Cheers,