Skip to main content

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 revision No specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-10-03
Requested 2012-08-10
Authors Kenji Kumaki , Tomoki Murai , Dean Cheng , Satoru Matsushima , PENG JIANG
I-D 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
Request Last Call review on draft-kumaki-murai-l3vpn-rsvp-te by Security Area Directorate Assigned
Result Ready w/issues
Completed 2012-09-28
review-kumaki-murai-l3vpn-rsvp-te-secdir-lc-hallam-baker-2012-09-28-00
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/