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

[Vincent Roca <[e-mail]>]

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

On 14/12/10 18:06, David Allan I wrote:
> 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:[e-mail]]
> Sent: Tuesday, December 14, 2010 3:11 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> 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:
> 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