Subject: [secdir] SecDir review of draft-ietf-mpls-tp-oam-framework-09

From: Vincent Roca <[email-masked]>
Date: Tue, 14 Dec 2010 12:10:57 +0100

Dear all,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

The Security Considerations section of this I-D is fairly strange.
The authors first highlight that OAM traffic contains sensitive
data (like passwords), and then quickly conclude that securing this
traffic is impossible and therefore they require that the network be
physically secured. The reason provided is the fact that there are
too many entities that are likely to communicate to establish and
maintain SAs between them.

Well, I don't know the specificities of MPLS networks, nor the
OAM operations in MPLS networks, however:
1- I need more information to be convinced that there is indeed no
    other solution than requiring that the whole physical network be
    totally secured;
2- I need more information to be convinced that fully securing such
    a physical network is feasible;

Honestly speaking I'm not convinced by 1-. What about solutions
based on temporary SA? Are the OAM exchanges so frequent to require
that each secure connection be maintained all the time? Would a
solution that establishes those connections on-the-fly, when needed,
be realistic? Another direction could be to use shared keys between
the entities of a group. Or perhaps using a per-packet signature
approach is feasible, using some public key infrastructure, if the
exchanges are infrequent. There are probably other IETF protocols
that have similar requirements. What about the KARP WG that focuses
on secure routing protocols? May some ideas be borrowed and applied
here (that's a fully open question)?

Concerning 2-, a quick search on "MPLS attacks" on the web provides
a small number of references. There's also a book on the subject
("Analyzing MPLS VPN Security", M. H. Behringer, M. Morrow, Cisco
Press, 2005). I don't known the domain at all but I'd like to be
convinced that 2- is feasible.

A minor comment.
I have the feeling that the authors use the term "man-in-the-middle
attack" to denote any attack where the attacker takes control of the
physical infrastructure. That's not an appropriate use and this term
refers to a very specific attack (e.g. see
http://en.wikipedia.org/wiki/Man-in-the-middle_attack).

I hope these comments are useful.
Regards,

    Vincent

---

From: David Allan I <[email-masked]>
Date: Tue, 14 Dec 2010 12:06:39 -0500

HI Vincent:

Thank you for the detailed read of the section and your comments....

There are a couple of problems associated with the volume of SAs required  that IMO there is no obvious way to mitigate...

The primary example that comes to mind is fault management...

1) Heartbeats are running between LSP endpoints at a an interval as low as 3.3msec interval. The number of SAs is bounded but applying some form of crypto per-packet authentication would just about melt any existing implementation. This discussion has already come up independently in the BFD WG w.r.t. the authentication option.

2) Applying authentication to the generation of notification messages from intermediate nodes in the path means the number of SAs goes up in direct proprotion to the number of hops in the path length of each LSP if the SAs are to be established prior to actually being required in the interest of timely generation of notifications. Negotiating the establishment of each SA on the fly would appear to add significant delays in what is supposed to be an instantaneous network response so does not appear to be a practical option for reducing the scaling impact of maintaining a full set of SAs for all eventualities...

Now we probably overstate the case for crypto in the section (reference to password exchange) and will edit accordingly. What we are exchanging is state about the operational status of a given entity with a minimum of authentication/non-repudiation exclusively on internal links to a network. If a malicious party is able to tap into one of those links they would be able to insert or modify transactions./messages as to mask the true state of the network. 

SO on the basis of the above any suggestions as to how the section can be improved would be welcome. BTW thanks for pointing out that man in the middle has a more specific context that our usage, we will edit accordingly.

Cheers
Dave

-----Original Message-----
From: Vincent Roca [mailto:[email-masked]] 
Sent: Tuesday, December 14, 2010 3:11 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: SecDir review of draft-ietf-mpls-tp-oam-framework-09

Dear all,

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

The Security Considerations section of this I-D is fairly strange.
The authors first highlight that OAM traffic contains sensitive data (like passwords), and then quickly conclude that securing this traffic is impossible and therefore they require that the network be physically secured. The reason provided is the fact that there are too many entities that are likely to communicate to establish and maintain SAs between them.

Well, I don't know the specificities of MPLS networks, nor the OAM operations in MPLS networks, however:

Honestly speaking I'm not convinced by 1-. What about solutions based on temporary SA? Are the OAM exchanges so frequent to require that each secure connection be maintained all the time? Would a solution that establishes those connections on-the-fly, when needed, be realistic? Another direction could be to use shared keys between the entities of a group. Or perhaps using a per-packet signature approach is feasible, using some public key infrastructure, if the exchanges are infrequent. There are probably other IETF protocols that have similar requirements. What about the KARP WG that focuses on secure routing protocols? May some ideas be borrowed and applied here (that's a fully open question)?

Concerning 2-, a quick search on "MPLS attacks" on the web provides a small number of references. There's also a book on the subject ("Analyzing MPLS VPN Security", M. H. Behringer, M. Morrow, Cisco Press, 2005). I don't known the domain at all but I'd like to be convinced that 2- is feasible.

A minor comment.
I have the feeling that the authors use the term "man-in-the-middle attack" to denote any attack where the attacker takes control of the physical infrastructure. That's not an appropriate use and this term refers to a very specific attack (e.g. see http://en.wikipedia.org/wiki/Man-in-the-middle_attack).

    Vincent

---

From: Adrian Farrel <[email-masked]>
Date: Wed, 15 Dec 2010 10:51:49 +0000

Thanks Vincent,

> Document editors and WG chairs should treat

Well, I shall ask the authors to treat them as comments that need to be
considered and discussed with possible document changes.

Were we to treat them like any other last call comments you would simply get a
response saying "thanks for your thoughts which we will examine to see whether
they can be useful, but please be aware that the last call completed some weeks
ago" :-)

Cheers,
Adrian

---

From: Vincent Roca <[email-masked]>
Date: Fri, 17 Dec 2010 14:55:38 +0100

Hello David,

Thanks for your answer and for the -10 version.

I see there are indeed good reasons not to encumber too much the
protocol with security stuff. This was not obvious at first glance for
a non specialist like me and a short simplistic security section is
often the sign that the authors didn't take time to think about it
(or don't have the required knowledge). This is not the case here.

However there's a (naive) question which you didn't answer: is it
realistic to assume the physical network can be secured? Are there
known weaknesses in the MPLS infrastructure? Nothing is said in
the I-D.

Another point (from -10). It is said:

         However
         it should be observed that the combination of the need for
         timeliness of OAM transaction exchange and all permutations of
         unique MEP to MEP, MEP to MIP, and intermediate system
         originated transactions mitigates against the practical
         establishment and maintenance of a large number of security
         associations per MEG either in advance or as required.

The reasons mentioned here to justify nothing is done is critical.
Only two reasons are listed: timeliness and combinatorial motivations.
In your answer you also mention the high transmission frequency of
heartbeats. This is not mentioned. Something else?

Cheers,

   Vincent