Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide
draft-ietf-karp-ospf-analysis-06

I have no objection to the publication of this document, but I have a
number of comments that I hope you will look at and consider as ways to
improve the value of the document.

---

Section 1

   This document performs the initial analysis of the current state of
   OSPFv2 and OSPFv3 according to the requirements of [RFC6518].

This suggests that a further analysis is required. What should it cover?
When will it be done? Who will do it?

---

Section 2.2

   There is another serious problem with the OSPFv3 security: rather
   than being integrated into OSPF, it is based on IPsec.  In practice,
   this has lead to deployment problems.

I think you probably need to expand on this to indicate what deployment
problems have been seen, and maybe why this is caused by the dependency
on IPsec.

Section 4 compounds the issue by saying 

   In order to encourage deployment of OSPFv3 security, an
   authentication option is required that does not have the deployment
   challenges of IPsec.

This challenges need to be described or you need to point at a
reference.

---

Section 3

I am a little surprised not to find any discussion of physical link 
security. Replay attacks rely on being able to send packets to an OSPF
receiver. On P2P links there are only three possibilities:

1. The peer has been subverted. In this case, a replay attack is the
   least damage that can be done!
2. A replay packet is tunneled to the receiver over multiple IP hops.
   This case is simply prevented by not allowing OSPF packets to be 
   received in this way. (I see you finally get round to talking about
   GTSM and ACLs in Section 7).
3. A node has been physically inserted on the link.

So it would appear that the third case needs to be discussed, and it
may be the case that the greatest vulnerability is on a multi-access
link because the ability to insert a node between two OSPF peers would
seem to allow far more amusing attacks than just replay.

---

Section 4

   In order to support the requirement for simple preshared keys, OSPF
   needs to make sure that when the same key is used for two different
   purposes, no problems result.

This is the first mention of this issue. 

---

Section 4

   In order to support packet prioritization, the information needed to
   prioritize OSPF packets (the packet type) MUST be at a constant
   location in the packet.

I don't agree with this. Previously you said (section 2.2)...

   For this reason, prioritizing packets
   may be more complex for OSPFv3.  One approach is to establish per-SPI
   filters to find the packet type and act accordingly.

...and that seems to agree with me that it is perfectly acceptable to 
operate with the packet type being located at different points in the 
packet. I would agree if you said it is desirable to enable a 
simplification, but "MUST" seems way too strong.

---

Section 5

   The key components of this solution work are already underway.
   OSPFv3 now supports an authentication option [RFC6506] that meets the
   requirements of this section, except that it does not describe how
   the key tables are used for OSPF.
                   
This is really weird! We have read this document so far in the belief 
that OSPFv3 is missing some key security aspects. And now you tell us 
that RFC 6506 (which is part of the OSPFv3 suite) already meets some of
the requirements. Now my understanding of the gap analysis is completely
confused. Are you saying that there is actually only one remaining gap
for OSPFv3?

===

The following are nits you should consider if you have the document open
for further edits...

---

Obviously need to fix the line that is longer than 72 characters.

---

Looks like [I-D.ietf-opsec-routing-protocols-crypto-issues] can be 
dropped fromthe references as it has become RFC 6039.

---

Refer to this document as a "document" not a "draft" to reduce the
work of the RFC Editor at a later stage.

Well written.  I just have a couple of minor non-blocking editorial suggestions for Section 1.1, which you may take or leave as you please:

   There are a number of requirements described in section 3 of
   [I-D.ietf-karp-threats-reqs] that OSPF does not currently meet:

What follows this is indented, and appears to all the world as a quotation from karp-threats-reqs.  I knew it couldn't be, and found that confusing.  I had to go look at karp-threats-reqs to check.

I suggest that you un-indent the subsequent paragraphs, and that you rephrase the above somewhat like this: "There are a number of requirements described in section 3 of [I-D.ietf-karp-threats-reqs] that OSPF does not currently meet.  The gaps are as follows:".  That would make it clearer that what follows is text in this document, not anything quoted from the other.


      Replay Protection: OSPFv3 has no replay protection at all.  OSPFv2
      has most of the mechanisms necessary for intra-connection replay
      protection.  Unfortunately, OSPFv2 does not securely identify the
      neighbor with whom replay protection state is associated in all
      cases.  This weakness can be used to create significant denial-of-
      service issues using intra-connection replays.  OSPFv2 has no
      inter-connection replay protection; this creates significant
      denial-of-service opportunities.

I found it hard to follow the combination of different versions of OSPF and different aspects of replays, put into the same paragraph.  Maybe a bullet list would be clearer:

      Replay Protection:

        *  OSPFv3 has no replay protection at all.

        *  OSPFv2 has most of the mechanisms necessary for
           intra-connection replay protection.  Unfortunately,
           OSPFv2 does not securely identify the neighbor with whom
           replay protection state is associated in all cases.  This
           weakness can be used to create significant denial-of-
           service issues using intra-connection replays.

        *  OSPFv2 has no inter-connection replay protection; this
           creates significant denial-of-service opportunities.

I agree with Adrian's comments.

I agree with Adrian's comments and would be tempted to raise some of
them, esp. regarding section 5, to a Discuss.

Formerly a discuss, addressed in an RFC Editor note:

Regarding the first sentence of section 5:

   A security solution will be developed for OSPFv2 and OSPFv3 based on
   the OSPFv2 cryptographic authentication option.

In general, passive voice is to be avoided.  In particular, how can
this document make an unilateral statement about what will be
developed and the technical details of the solution?

It be useful to note that most networks running OSPF mitigate its vulnerabilities by blocking all OSPF traffic at the network edge.

  Please consider the non-blocking comments from the Gen-ART Review
  by Elwyn Davies on 5-Nov-2012.  You can find the review here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07898.html

Nicely done - one comment and then some nits:

There's but one requirement in this draft:

 In order to support packet prioritization, the information needed to
 prioritize OSPF packets (the packet type) MUST be at a constant
 location in the packet.

Seems like an odd requirement for a security analysis draft.  Can you explain the motivation for it in this draft a bit more?


And now for the nits:

0) You've got two requirements language paragraphs.

1) I thought the same thing as Adrian did about the 1st sentence in s1.  Maybe:

 r/performs the initial analysis of the
  /analyzes the 

2) s1, para 2: Should you specify that when OSPF is used you're referring to both OSPFv2 and OSPFv3?  Also, the mention of OSPFv2 in the last paragraph made me wonder whether you should also say something like: 

 while the currently OSPFv3 security solution can interfere with prioritization.

3) s1, para 3: Can you strike " the requirements" from the following:

  However, some gaps remain between the current state and the
   requirements for manually keyed routing security expressed in
   [I-D.ietf-karp-threats-reqs] the requirements.

4) s1.1, PSK (and later s4 and s5): Could drop "simple" because it doesn't appear in the karp requirement and one person's simple is another person's complex.

5) s2.1, para 2: Shameless plug for RFC 6151, which provides an update to the MD5 security considerations and supports your assertion that MD5 ought not be used going forward.

6) s2.2, para 1: Maybe add IPsec in the first para:

  r/how the authentication header/how the IPsec authentication header 

7) s2.2, last para: Are you saying that just the integrity algorithm matters here?  Isn't it the entire suite?

   When IPsec is used with OSPFv3, the offset of
   the packet type, which is used to prioritize packets, depends on what
   integrity transform is used.

I think it'd be good if this: "The key components of this
solution work are already underway." was stated up front.
Keeping the good news for the very end seem mean:-)