Subject: [secdir] Secdir review of draft-ietf-l3vpn-end-system-04

From: "Brian Weis (bew)" <[email-masked]>
Date: Tue, 9 Dec 2014 03:18:38 +0000

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.

This subject of this document is "BGP-signaled end-system IP/VPNs”, which defines a system where an L3VPN system is supported  on “end systems", which means servers sitting in a data center. It describes how the L2VPN control plane and forwarding plane can be implemented in a network virtualization environment. Three actors are described, which together implement the L3VPN PE role. 

The security goal of the L3VPN is to maintain isolation between sets of users (e.g., customers of a provider). A new XMPP-based signaling protocol is described in order for two of the actors (“End System” and “End System Route Server”) to pass IP reachability information for each set of users.

The Security Considerations section is fairly light. It should be a bit more verbose in describing the new threats that this system have over and above a traditional L3VPN. The following comments try to tease out what those threats might be.

1. The first paragraph of Security Considerations says “It is important to secure the end-system access to End-System Route Servers and the BGP infrastructure itself.” I’m not sure if this is intended to mean that the end-system (and it’s virtual machines) aren’t trusted and should be isolated from the RSs and BGP infrastructure, or if this a preamble to the next paragraph stating that the XMPP session needs to be secured. 

But in either case since the L3VPN PE functionality is now no longer physically isolated form the customer images, it is important to describe what new threats this approach adds to the PE role.  Maybe the last paragraph in the section is trying to make the point that there are new threats, but if so should say more about the need for separation of virtual and infrastructure traffic. E.g., this mitigates traffic from a  virtual machine attacking the infrastructure traffic or creating a denial of service by clogging up the infrastructure with frames.

2. The second paragraph of Security Considerations mentions that the XMPP session needs to be secured. It describes the use of certificates, but this isn’t enough. Certificates need to be used with a protocol that uses certificates for peer authentication. I think it’s common to protect XMPP with TLS, for example so you might want to look into that. Once a peer is authenticated with its certificate, then the router server can perform authorization. It is important to give at least one complete example of a method to secure the session.

3. The third paragraph of Security Considerations mentions a couple of conventional methods for securing BGP. Is this more than what is typically recommended within an L3VPN BGP (as opposed to a BGP speaker connected to another provider)? If so, it would be good to say what are the additional threats that require more security.

4. Section 6 mentions external Forwarders, and says that in this case "VPN routing information received from the Route Server(s) SHOULD NOT be propagated to the end-system.” Is there a security consideration here?

Brian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 9 Dec 2014 12:58:28 -0000

Thanks Brian,

Authors: please develop updates or a response.

Thanks,
Adrian

> -----Original Message-----
> From: iesg [mailto:[email-masked]] On Behalf Of Brian Weis (bew)
> Sent: 09 December 2014 03:19
> To: [email-masked]; The IESG
> Cc: [email-masked]
> Subject: Secdir review of draft-ietf-l3vpn-end-system-04
> 
> 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.
> 
> This subject of this document is "BGP-signaled end-system IP/VPNs", which
> defines a system where an L3VPN system is supported  on "end systems", which
> means servers sitting in a data center. It describes how the L2VPN control
plane
> and forwarding plane can be implemented in a network virtualization
> environment. Three actors are described, which together implement the L3VPN
> PE role.
> 
> The security goal of the L3VPN is to maintain isolation between sets of users
> (e.g., customers of a provider). A new XMPP-based signaling protocol is
> described in order for two of the actors ("End System" and "End System Route
> Server") to pass IP reachability information for each set of users.
> 
> The Security Considerations section is fairly light. It should be a bit more
verbose
> in describing the new threats that this system have over and above a
traditional
> L3VPN. The following comments try to tease out what those threats might be.
> 
> 1. The first paragraph of Security Considerations says "It is important to
secure
> the end-system access to End-System Route Servers and the BGP infrastructure
> itself." I'm not sure if this is intended to mean that the end-system (and
it's
> virtual machines) aren't trusted and should be isolated from the RSs and BGP
> infrastructure, or if this a preamble to the next paragraph stating that the
XMPP
> session needs to be secured.
> 
> But in either case since the L3VPN PE functionality is now no longer
physically
> isolated form the customer images, it is important to describe what new
threats
> this approach adds to the PE role.  Maybe the last paragraph in the section is
> trying to make the point that there are new threats, but if so should say more
> about the need for separation of virtual and infrastructure traffic. E.g.,
this
> mitigates traffic from a  virtual machine attacking the infrastructure traffic
or
> creating a denial of service by clogging up the infrastructure with frames.
> 
> 2. The second paragraph of Security Considerations mentions that the XMPP
> session needs to be secured. It describes the use of certificates, but this
isn't
> enough. Certificates need to be used with a protocol that uses certificates
for
> peer authentication. I think it's common to protect XMPP with TLS, for example
> so you might want to look into that. Once a peer is authenticated with its
> certificate, then the router server can perform authorization. It is important
to
> give at least one complete example of a method to secure the session.
> 
> 3. The third paragraph of Security Considerations mentions a couple of
> conventional methods for securing BGP. Is this more than what is typically
> recommended within an L3VPN BGP (as opposed to a BGP speaker connected to
> another provider)? If so, it would be good to say what are the additional
threats
> that require more security.
> 
> 4. Section 6 mentions external Forwarders, and says that in this case "VPN
routing
> information received from the Route Server(s) SHOULD NOT be propagated to
> the end-system." Is there a security consideration here?
> 
> Brian
>

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Wed, 10 Dec 2014 03:50:56 +0000

This document is establishing a container for publicly available enumeration values to be included in an IODEF [IODEF] document. Several questions about the proposed solution are listed as follows. 
1)	In this specification, a given enumeration is uniquely identified by the specIndex attribute. However the usage of ID is not clearly introduced. In the security consideration section, it is mentioned that the miss-match between the index and the ID may cause problem. Could you please give me some clues?
2)	Where is section 2.2?
3)	In the abstract, it is stated that "This memo establishes a stand-alone data format to include both the external specification and specific enumeration value,. However, I didn't find the specific enumeration value in the example provided in Section 2.1:
"      <iodef:Reference>
         <iodef-enum:ReferenceName specIndex="1">
            <iodef-enum:ID>CXI-1234-XYZ</iodef-enum:ID>
         </iodef-enum:ReferenceName>
         <iodef:URL>http://cxi.example.com</iodef:URL>
         <iodef:Description>Foo</iodef:Description>
      </iodef:Reference>
"
Cheers

Dacheng

---

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 12 Dec 2014 11:15:33 -0600

Hi Dacheng,

Thank you for your review…responses inline.

Adam

> On Dec 9, 2014, at 9:50 PM, Zhangdacheng (Dacheng) <[email-masked]> wrote:
> 

The enumeration specification is identified, so that the ID expressed in a given IODEF (note v2 not v1) is understood.  The ID is a reference to a set of further information to be acquired through other means.  As an example, discovered vulnerabilities are often given a Common Vulnerability Enumeration (CVE) identifier.  This ID would be in the <iodef:enum:ID> element, and the specification for that ID’s format is what is pointed to by the IANA registry.  

> 2)	Where is section 2.2?

Good catch, thank you.

> “

That sentence should probably read (emphasis added): This memo establishes a stand-alone data format to include both the external specification and specific enumeration *identification* value.

> Cheers
> 
> Dacheng
> 
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Tue, 23 Dec 2014 06:14:36 +0000

Hi, Adam:

Thanks a lot for your reply. I have no additional comments now.

Cheers

Dacheng
> From: Adam W. Montville [mailto:[email-masked]]
> Sent: Saturday, December 13, 2014 1:16 AM
> To: Zhangdacheng (Dacheng)
> Cc: [email-masked]; The IESG;
> [email-masked]
> Subject: Re: [secdir] Secdir review of draft-ietf-mile-enum-reference-format-10
> 
> Hi Dacheng,
> 
> 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.
> >
> > This document is establishing a container for publicly available enumeration
> values to be included in an IODEF [IODEF] document. Several questions about
> the proposed solution are listed as follows.
> > 1)	In this specification, a given enumeration is uniquely identified by the
> specIndex attribute. However the usage of ID is not clearly introduced. In the
> security consideration section, it is mentioned that the miss-match between
> the index and the ID may cause problem. Could you please give me some clues?
> 
> The enumeration specification is identified, so that the ID expressed in a given
> IODEF (note v2 not v1) is understood.  The ID is a reference to a set of further
> information to be acquired through other means.  As an example, discovered
> vulnerabilities are often given a Common Vulnerability Enumeration (CVE)
> identifier.  This ID would be in the <iodef:enum:ID> element, and the
> specification for that ID’s format is what is pointed to by the IANA registry.
> 
> 
> > 2)	Where is section 2.2?
> 
> Good catch, thank you.
> 
> > 3)	In the abstract, it is stated that "This memo establishes a stand-alone
> data format to include both the external specification and specific enumeration
> value,. However, I didn't find the specific enumeration value in the example
> provided in Section 2.1:
> > "      <iodef:Reference>
> That sentence should probably read (emphasis added): This memo establishes
> a stand-alone data format to include both the external specification and
> specific enumeration *identification* value.
> 
> > Cheers
> >
> > Dacheng
> >