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 Gen-art@ietf.org http://www.ietf.org/mailman/listinfo/gen-art
