Subject: [secdir] SECDIR Review of draft-kumaki-murai-l3vpn-rsvp-te/

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 21 Sep 2012 13:19:17 -0400

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 specification describes a mechanism for exchanging RSVP routing
information to support multi-site VPNs in the case that a connection
supports multiple VPNs.

The document lacks a substantive security considerations section, instead
referencing RFC3209 for security considerations. I do not think this is
appropriate since that document was published in 2001 when security
considerations were still insubstantial and in the case ofd RFC 3209
consist of a reference to RFC 2205 which is also pro-forma.

rfc6437 has a much better presentation of the issues involved.

While people tend to use Security Considerations to list the problems with
a protocol there is no real reason this should be the case. The SC should
address all the considerations, positive and negative

Here we have a model where the VPN is providing authentication and
integrity checking end to end. That only leaves service and traffic
analysis as concerns with respect to routing level attacks. But there
should be discussion of the possibility that a member of the VPN network
might introduce malicious routing data to redirect traffic. Either to do
traffic analysis or to perform a DoS attack.

While this is not something members of a VPN are likely to do
intentionally, it is something an attacker might do if they own one site.
The risk here is that when you join a VPN club you may be exposing yourself
to the vulnerabilities/exploits of the weakest member of the club. And they
may be able to clobber you through them. So large scale systems might well
have rules about auditing and security policies they would need in place.
They should also sanity check the routes advertised.

Using a VPN does have a penalty as well as it means that the packet
contents are now opaque to the good guys as well as the bad. Port filtering
is no longer possible, spam filtering is hard and so on.

-- 
Website: http://hallambaker.com/

---

From: Peng JIANG <[email-masked]>
Date: Fri, 28 Sep 2012 09:14:46 +0900

Dear Phillip, 

Thank you for your detailed Security review of our draft. We 
will endeavor to review and update our draft based on your 
recommendations, use cases and referral to RFC6437. Our plan is 
to address the Security aspect and any further IESG comments in 
a new version of draft after Last Call has completes. If ok I 
will contact you with our new Security text to confirm it is 
suitable for addressing the issues you raise. 

Thank you. 
Peng