draft-ietf-ppvpn-generic-reqts

[Steve Bellovin <smb@research.att.com>]

        Doesn't seem to use 2119 language, even though it says it does
        4.4: disclosure of signaling info needs to be filtered per
                extranet agreement
        4.5: DoS includes CPU attacks on CPE/PPE
        4.5.2: Does access control include cryptographic mechanisms?
        4.7: Does "support overlapping addresses" mandate NAT?  Do we
                really want to mandate that?
        5.1.1: I find some of the scaling numbers dubious.  10^5
                routes in a single VPN?  I find that implausible.
        5.1.2.1: By contrast, I find 10^3 users per site to be too low.
        5.1.2.2: Ditto 10^2 sites per VPN
        5.1.2.6: Ditto 100 sites/customer.
                Note:  I'm thinking of a large company with many sites,
                which uses a VPN fors its primary intrasite connectivity.
                Wal-Mart is an extreme case, but have a look at
                http://www.business2.com/articles/mag/0,1640,37760,FF.html
                for some figures.
        5.1.3: I don't understand how "PE-based VPNs scale better than
                CE-based VPNs".  We're told that a PE must support 10^4
                sites, implying that there's a need for huge boxes.
                Can they be built that large, economically?  By
                contrast, a CE only needs to support its fanout,
                and they say 100 sites/customer.  (Btw -- there's no
                expansion of CE or PE in the document.)
                There's no discussion of hybrid solutions, such as
                a star with a PE center and CE edge nodes.
        7: There needs to be a lot more discussion of the "P" property
                of VPNs.  Different choices of VPN technology have
                different assurance levels of the privacy of
                a customer's network.  For example, CE-based
                solutions are probably more private than PE-based
                solutions if there's any sort of authentication of
                the remote end of the tunnel (even non-cryptographic),
                since it's hard for a mistake or equipment bug to send
                traffic to the wrong place.  In a PE node with 10K sites,
                half of which are using 1918 addresses, provisioning
                mistakes and PE software bugs seem very plausible.


		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)