Subject: [Gen-art] gen-art early review of draft-ietf-mpls-mpls-and-gmpls-security-framework-01.txt

From: Scott Brim <[email-masked]>
Date: Tue, 26 Feb 2008 09:02:39 -0800

I am the assigned Gen-ART reviewer for
draft-ietf-mpls-mpls-and-gmpls-security-framework-01.txt

For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please resolve these comments along with any other comments you may
receive.

Summary: This draft is on the right track but has open issues,
described in the review.

Detailed comments:

I started my review a few days ago before -02 came out.  I've
continued with the review of -01 in hopes that -02 hasn't changed too
much.

I'm not a security expert and I've forgotten most of what I knew about
[G]MPLS, so in this review I am looking first for internal consistency
and organization, and second for the areas where I do know a few
things.

In general I'm impressed with the wealth of the information and the
thoroughness.  I am mostly concerned about organization and possible
duplication.

Some of these comments are small, some are significant.  I've left
them in the order of the document itself.  Originally I had a bunch of
editorial suggestions but I've pulled them out except where they
clarified meaning.

>    Depending on different MPLS or GMPLS techniques used, the degree
>    of risk and the mitigation methodologies vary. This document
>    discusses the security aspects and requirements for certain basic
>    MPLS and GMPLS techniques and inter-connection models. This
>    document does not attempt to cover all current and future MPLS
>    and GMPLS technologies, as it is not within the scope of this
>    document to analyze the security properties of specific
>    technologies.

... is general, not just about inter-AS or -domain.  Make it a new
paragraph.  
     
>    Layer 2: The protocol layer under layer 3 (which therefore offers 
>    the services used by layer 3).  Forwarding, when done by the 
>    swapping of short fixed length labels, occurs at layer 2 regardless 
>    of whether the label being examined is an ATM VPI/VCI, a frame 
>    relay DLCI, or a MPLS label. 
>     
>    Layer 3: The protocol layer at which IP and its associated routing 
>    protocols operate. 
>     
>    Link Layer: Synonymous with layer 2.

I won't argue much here because I know you have to be consistent with
other, older documents but these definitions of "layers" don't work,
and even ITU has mostly abandoned them.  If I run IP over IP, is one
of them Layer 2?  "Link layer"?  What about IP over Ethernet over IP?
The best thing to do would be to get rid of all references to
"layers", and just talk about "the IP level", "MPLS" and so on.  That
way you could delete these definitions and also avoid ambiguity.  I
would say this about every new draft.

>    P: Provider Router. A Provider Router is a router in the Service 
>    Provider's core network that does not have interfaces directly 
>    towards the customer. A P router is used to interconnect the PE 
>    routers.

"Core" seems to be used in multiple ways, not all clear.  Here you
depend on having a meaning for "service provider's core network", but
you don't define it until you get to the security framework text
below.  Also, below you define a "MPLS/GMPLS core network" as possibly
spanning multiple service providers, and "an MPLS/GMPLS core in a
single domain".  I think I know where you come out, because as you go
on it seems to get better, but I suggest you make it clearer up here?
 
>    A MPLS/GMPLS core network is defined here as the central network 
>    infrastructure (P and PE routers). A MPLS/GMPLS core network 
>    consists of one or more SP networks.

See comment about uses of "core".

>     This document defines each MPLS/GMPLS core in a single domain to

"core" here too

>    4.1. Attacks on the Control Plane 
   
All of the user plane attacks can also be done on the packets of the
control and management planes: insertion of garbage, spoofing, replay,
delection, pattern analysis, etc.

>    5.1.1.         Management System Authentication 
>  
>    Management system authentication includes the authentication of a
>    PE to a centrally-managed network management or directory server
>    when directory-based "auto-discovery" is used.  It also includes
>    authentication of a CE to the configuration server, when a
>    configuration server system is used. 

Even in the management plane, authentication should be in both
directions.  The PE or CE deserves to have confidence that it is
talking to the right server.

>    It should be stressed that IPsec encryption 
>    without an integrity check is a state of sin. 

:-)  Leave this in.

>    MPLS and GMPLS, which provide differentiated services based on 
>    traffic type, may encounter some conflicts with IPsec encryption of 
>    traffic.  Because encryption hides the content of the packets, it 
>    may not be possible to differentiate the encrypted traffic in the 
>    same manner as unencrypted traffic.  Although DiffServ markings are 
>    copied to the IPsec header and can provide some differentiation, 
>    not all traffic types can be accommodated by this mechanism. 

This feels like a change of subject.  The primary topic was protecting
traffic while it is being carried by MPLS/GMPLS (or its ctl/mgmt
traffic).  This section, though, is about traffic which is already
encrypted when it hits an ingress LSR.  It's a very different issue,
but it seems to be mixed in.  Maybe you could have a different
subsection, or at least a sentence explaining that you are changing
issues.

>    5.5. Use of Aggregated Infrastructure

You talk about resource protection, but what about other attacks /
mistakes that shared infrastructure makes possible, other than just
using all the bandwidth.
    
>    7. Service Provider General Security Requirements

I have issues with the organization of the document.  You start with
"threats", then talk about "defensive techniques", and *then* have
sections on requirements.  Perhaps you could combine requirements and
threats?  In any case I don't see why requirements come after threats.

Not only that but this section is not just requirements, it's also
techniques.  For example,

>    The network infrastructure must support mechanisms for
>    authentication of the control plane. If MPLS/GMPLS core is used,
>    LDP sessions may be authenticated by use TCP MD5, in addition,
>    IGP and BGP authentication should also be considered. ...

This is mostly solution, not requirements.  

Or consider, just as an example, this section, which is still under
"requirements".  Where are the requirements here:

> 7.1.3. Control plane protection with LDP 
> 
>    The approaches to protect MPLS routers against LDP-based attacks
>    are similar to those for RSVP, including isolation, protocol
>    deactivation on specific interfaces, filtering of LDP neighbors
>    at the protocol level, filtering of LDP neighbors at the data
>    plane level (access list that filter the TCP & UDP LDP ports),
>    authentication with message digest, rate limiting of LDP messages
>    per protocol per sender and limiting all resources allocated to
>    LDP-related tasks.

I'm not against any of the information, it's all good, but I would
organize it differently so that requirements are labeled as such, and
so on.  Maybe all you have to do is change the section titles.  This
gets much better down in Section 8.
    
Thanks ... Scott
_______________________________________________
Gen-art mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/gen-art