Subject: RE: draft-fang-ppvpn-security-framework-01.txt

From: "Paul Knight" <[email-masked]>
Date: Mon, 18 Aug 2003 11:57:39 -0400

Hi Stewart,

Thanks for your comments.

Responses to some parts of your questions, regarding section 4:

> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]] 
> Sent: Wednesday, July 30, 2003 1:00 PM
> To: Ron Bonita; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: draft-fang-ppvpn-security-framework-01.txt
> 
[...]
> 
> 
> 4.1.    Cryptographic techniques
> 
>     Packet lengths are typically increased when the packets are
>     encrypted, increasing the network traffic load and adding to the
>     likelihood of packet fragmentation with its increased overhead.
> 
> SB> Do you want to talk about MTU here?
It's difficult to do justice to the MTU issues without bloating the
document, but I'm thinking of expanding the existing parenthetical mention
of compression to include it:

(This packet length increase can often be mitigated to some extent by data
compression techniques, but at the expense of additional computational
burden. It could also be mitigated by decreasing the path MTU perceived by
the user VPN sites, so that encrypted packets will not require
fragmentation. However, MTU discovery is not reliably active in end systems
in current IPv4 networks, so this may be of little benefit in avoiding
packet fragmentation. Also, causing a reduction of the MTU within the user's
sites violates a common PPVPN goal of minimizing changes to the user's
network.) 
> 
> 
> 4.1.3.  Cryptographic techniques in Layer 2 PPVPNs
> 
>     Layer 2 PPVPNs will generally not be able to use IPsec to provide
>     encryption throughout the entire network.  They may be able to use
>     IPsec for PE-PE traffic where it is encapsulated in IP packets,
> 
> SB> Does this mean that we need an MPLSsec work item?

We've essentially got it in draft-ietf-l3vpn-ipsec-2547-01.txt, which is the
approach which this refers to. I don't plan to include the reference in the
draft, however.
> 
> 
> 4.3.    Access Control techniques
> 
> SB> Should you you call out the use of internal only addresses for
> SB> the VPN infrastructure? This is called up later - perhaps a
> SB> forward reference?

- I'll include a reference, and expand the description of internal-only
addresses in 4.4.  It's definitely a frequently-used part of isolated
infrastructure which we hadn't mentioned. 

Reference reads:
 Enforcement of access control by isolated infrastructure addresses is
discussed in another section of this document.
> 
> 
> 4.4.    Use of Isolated Infrastructure
> 
>     One way to protect the infrastructure used for support of 
> VPNs is to
>     separate the resources for support of VPNs from the resources used
>     for other purposes (such as support of Internet services). In some
>     cases this may make use of a physically separate equipment for VPN
>     services, or even a physically separate network.
> 
>     For example, PE-based L3 VPNs may be run on a separate 
> backbone not
>     connected to the Internet, or may make use of separate 
> edge routers
>     from those used to support Internet service.
> 
> SB> This is where local (to the provider) addresses help.

Added:
 Private IP addresses (local to the provider and non-routable over the
Internet) may be used to provide additional separation.

[...]

Regards,
Paul