Last Call Review of draft-kumaki-murai-l3vpn-rsvp-te-
review-kumaki-murai-l3vpn-rsvp-te-secdir-lc-hallam-baker-2012-09-28-00

Request Review of draft-kumaki-murai-l3vpn-rsvp-te
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-10-03
Requested 2012-08-10
Draft last updated 2012-09-28
Completed reviews Genart Last Call review of -?? by Christer Holmberg
Genart Last Call review of -?? by Christer Holmberg
Genart Telechat review of -07 by Christer Holmberg (diff)
Secdir Last Call review of -?? by Phillip Hallam-Baker
Assignment Reviewer Phillip Hallam-Baker
State Completed
Review review-kumaki-murai-l3vpn-rsvp-te-secdir-lc-hallam-baker-2012-09-28
Review result Ready with Issues
Review completed: 2012-09-28

Review
review-kumaki-murai-l3vpn-rsvp-te-secdir-lc-hallam-baker-2012-09-28

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/