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

[Peng JIANG <[e-mail]>]

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  

> 
> 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/
> 
> 
>