Subject: Re: draft-ietf-ppvpn-ce-based-02.txt

From: [email-masked]
Date: Thu, 01 Aug 2002 17:00:19 +0200

Eric,

> Jeremy> the CE  participates in two  routing realms: the  customer's private
> Jeremy> routing realm  (this is not considered in  this particular section),
> Jeremy> and the SP's routing realm. The assumption is that the CE has one IP
> Jeremy> address  that belongs  to the  SP's realm  (that it  should  not use
> Jeremy> internally in it's private intra-VPN routing), and that the CE knows
> Jeremy> how  to   send  IP  packets   towards  destinations  in   that  SP's
> Jeremy> realm. Usually, a default route towards the PE will suffice (this is
> Jeremy> a  default  route in  the  SP's routing  realm,  for  the 'outer  IP
> Jeremy> header'; not  to be  confused with a  possible default route  in the
> Jeremy> customer's routing realm, e.g. towards a specific peer CE).
> 
> So  the  CE may  maintain  two  default routes,  one  in  each realm?   This
> suggests that the CE must  maintain two different forwarding tables, one for
> the SP realm and one for the private realm.  Now we're talking about CE that
> is specially designed for VPN  support.  Or have I misunderstood?  The other
> L3VPN proposals do not require VPN-specific stuff in the CEs.

Isn't that the difference between CE-based and PE-based VPNs ? The other
L3VPN proposals require VPN-specific stuff in the PEs... CE-based VPNs
shouldn't (the filtering for unauthorized Internet access issue set
asside for a moment..)
 
> Actually, if  you are going  to allow the  CEs to have  SP-facing interfaces
> whose addresses are not distinct from the addresses used in the VPN, I think
> you have no  choice but to maintain two separate  forwarding tables, one for
> tunnel endpoints and one for everything else.

We could call this 'separate forwarding tables', VRFs, VFIs, VRs etc. if
that makes it easier to understand. But whether this is implemented as
separate forwarding tables is implementation-specific, no ? As long as
the behavior is as requested.. One forwarding table is clearly in the
customer address space, the one you called "for everything else". The
requirement is really that as a result of a lookup in that forwarding
table, packets can be forwarded towards a specific VPN outgoing
interface. Such an interface can either be an interface within the
customer site, or a virtual interface on the CE-PE link.

A virtual interface will correspond with a specific (additional) IP
encapsulation. These virtual interfaces (SA, DA) are created and deleted
through VPN provisioning, not through routing.

I didn't really see this behavior as the implementation of a second
virtual forwarding table, but rather as the provisioning of virtual
interfaces. But anyway I agree that the CE will need to forward in 2
different forwarding spaces (as in Layer-3 forwarding over Layer-2
'forwarding' rather than in twice Layer-3 forwarding at the same level
as is the case with VRFs) and that the CE will need to be able to do
VPN-specific functions such as routing and forwarding through "virtual
interfaces".

> Jeremy> The CE is not a routing  peer in the SP's core routing algorithm for
> Jeremy> it's  internal  VPN routes,  only  for  the  (one) IP  address  that
> Jeremy> identifies that CE in the  SP's routing realm. This doesn't add much
> Jeremy> burden,  as  the  CE  will  not  be injecting  routes  in  the  core
> Jeremy> routing.
> 
> You really  don't want the CE  to be a  routing peer at all.   In algorithms
> like OSPF, the number of routing peers may be a bigger issue than the number
> of routes.

Agreed.
 
> Jeremy> Normally the  CE will  just be  configured with  a default
> Jeremy> route towards the PE and the PE will have a static route towards the
> Jeremy> CE.
> 
> >> **** Perhaps what is  wanted is that the CE should get  the SP's routes, but
> >> **** shouldn't send it's own routes to  the SP.  The PE would have to filter
> >> **** out any routes the  CE tries to send it.  Really one  only wants the CE
> >> **** to see  routes via the  PE to other  CEs in the  same VPN, but  I don't
> >> **** think the draft provides any such mechanism.
> 
> Jeremy> Should we mandate the provisioning  of a default route towards to PE
> Jeremy> ?
> 
> Again, this question assumes two routing tables, I think.
> 
> If  the CE  is  multiply connected,  this  may not  be  desirable.  In  that
> situation, the CE  would like to have the SP's routing  metrics to the other
> CEs.  You'd  probably end up  running a small  RIP domain between PE  and CE
> (containing only those two routers)  into which are redistributed the routes
> from the SP's core.  However, there are issues with this as well.

Multiply connecting one CE to different PEs brings up quite some
additional issues indeed...

Is the only 'easy' alternative for multiple connected sites to have two
CEs ?

Is multiple connect via one CE a hard requirement for CE-based PPVPNs ?

> >> **** This seems  to provide Internet  access automatically, whether  that is
> >> **** intended  or not.   Or perhaps  the  PE needs  to filter  out all  data
> >> **** traffic from the CE that isn't to another CE.  While this would prevent
> >> **** unintended Internet access, I don't see  how this would be done, as the
> >> **** PE doesn't know which IP addresses correspond to CEs.
> >>
> >> **** This makes me  wonder how the SP could  avoid providing Internet access
> >> **** to all the CEs.  There'd need to  be some way to make sure that there's
> >> **** nothing the customer can do to a CE that will let the CE send non-VPN
> >> **** traffic to  the PE, and that  a PE will  not accept any traffic  over a
> >> **** particular  interface  unless  it  comes from  a  "properly  configured
> >> **** managed" CE.  But I don't really understand how this is to be done.
> 
> Jeremy> You bring up an interesting point !
> 
> Jeremy> Maybe the answer is that this VPN approach is always to be used in
> Jeremy> combination with providing Internet access ?
> 
> I don't think so, as that would require a corporate firewall at every site.

Let me rephrase. Internet Access is not provided by default at every
site. Packets from within the site destined for the Internet will either
be discarded (no entry in the CE's VPN forwarding table) or be sent (=
tunnelled) to a specific peer CE (default entry in the VPN forwarding
table). The thing that we can maybe not prohibit is that someone who
takes the place of the CE device uses the interface towards the PE to
send and receive Internet traffic. I don't know whether this is
something to worry about, because the customer who would want to do that
would either pay for provisioning of a VPN site and use it for Internet
access or tamper with the security of its own VPN.

> 
> Jeremy> [just making this  up now..] Or maybe the IP  addresses used for CEs
> Jeremy> that participate in VPNs can be distinguished from the ones that are
> Jeremy> used  for  CEs  that  don't   participate  in  VPNs  and  have  only
> Jeremy> eg. Internet access  ?  Without the need for every  PE to know which
> Jeremy> CE gets which  specific address. As such, every  PE should only know
> Jeremy> whether his attached  CEs have received Internet access  or not, and
> Jeremy> which 'pool' (/prefix) of IP  addresses (in the SP's realm) is being
> Jeremy> used for the 'outer' IP addresses used by the VPNs.
> 
> This will have multi-provider and Internet transparency issues.

yes :-(

> 
> >> **** What  stops a  CE from  simply sending  traffic to  a CE  that is  in a
> >> **** different VPN?  Or is it just the latter CE's responsibility to discard
> >> **** such  traffic?  But  then  how exactly  does  it know  what traffic  to
> >> **** discard?  Especially if it is supposed to be receiving Internet traffic
> >> **** as well as VPN traffic?
> 
> Jeremy> It is the latter CE's responsibility to discard such traffic. It knows
> Jeremy> what traffic to discard based on the security associations. [anyway, if
> Jeremy> the traffic is encrypted, it will not be able to decrypt it.]
> 
> The interesting case is where the traffic is not encrypted.  Two enterprises
> which  are not paying  for Internet  access or  for extranet  capability may
> still be able to talk to each  other over the provider's network, as long as
> each one has VPN service from that provider.

They could only do this by explicitly playing with the CE device and the
CE-PE interface, at a high security risk. This doesn't seem like a very
probable scenario.

> 
> >> **** Please   consider   multi-provider   [management]  issues.    In   a
> >> **** multi-provider VPN, this kind of technique seems to require one SP's
> >> **** management system to provision the CEs attached to another SP.  This
> >> **** seems to me to be an unlikely scenario.
> 
> Jeremy> the second SP may be only offering Internet access to the CEs, and be
> Jeremy> unaware of the fact that the CEs participate in the VPN managed by the
> Jeremy> former SP.
> 
> Or not.  Consider the case in which half of the VPN's sites attach to one SP
> and half to another.  Now, what information needs to be under the control of
> what management systems?

SP1 will control all the security information and will provision all
CEs. SP1 will need to know which IP addresses SP2 will assign to the CEs
that are attached to SP2 (I'm talking about the 'outer' IP addresses
used for the virtual interfaces).

Anyway, I think we'll try to fix the single-SP case before the multi-SP
case... as the other L3VPN approaches have done.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 01 Aug 2002 11:38:02 -0400

>> L3VPN proposals do not require VPN-specific stuff in the CEs.

Jeremy> Isn't that the  difference between CE-based and PE-based  VPNs ? The
Jeremy> other   L3VPN   proposals   require   VPN-specific  stuff   in   the
Jeremy> PEs...  CE-based  VPNs  shouldn't  (the filtering  for  unauthorized
Jeremy> Internet access issue set asside for a moment..) 

I think  the assumption has been  that any router which  provides the proper
IPsec support and the proper secure management support could be used as a CE
router  for a  CE-based VPN.   The requirement  to support  multiple routing
tables and/or address spaces goes way beyond this, as  that sort of support
is generally  only found in  routers built to  be PEs.  I'm not  saying that
that  requirement is  unacceptable,  only that  it  hasn't been  articulated
before and I want to be sure it is well understood.

>> whose addresses  are not distinct from  the addresses used in  the VPN, I
>> think you have no choice  but to maintain two separate forwarding tables,
>> one for tunnel endpoints and one for everything else.

Jeremy> We  could call this  'separate forwarding  tables', VRFs,  VFIs, VRs
Jeremy> etc.  if  that makes it easier  to understand.  But  whether this is
Jeremy> implemented  as   separate  forwarding  tables   is  implementation-
Jeremy> specific, no ? As long as the behavior is as requested.  

All these notions,  VRF, VFI, VR are functional notions  that do not require
any particular implementation.  

Jeremy> I didn't really see this behavior as the implementation of a second
Jeremy> virtual forwarding table, but rather as the provisioning of virtual
Jeremy> interfaces. 

But  the route  to the  remote endpoint  of the  tunnel is  not part  of the
virtual  interface  configuration.   Rather,  that  route  is  obtained  via
routing.   That  is why  we  need  to think  of  there  being two  different
forwarding tables. 

Jeremy> Is  multiple connect  via one  CE  a hard  requirement for  CE-based
Jeremy> PPVPNs ? 

I don't know,  the SPs will have to  say, but the absence of  such a feature
would probably not be regarded as an advantage.

Jeremy> Internet Access  is not provided  by default at every  site. Packets
Jeremy> from  within the  site  destined  for the  Internet  will either  be
Jeremy> discarded (no entry in the CE's  VPN forwarding table) or be sent
Jeremy> (tunnelled)  to  a  specific  peer  CE  (default  entry  in  the  VPN
Jeremy> forwarding table). The thing that  we can maybe not prohibit is that
Jeremy> someone  who takes the  place of  the CE  device uses  the interface
Jeremy> towards the  PE to send and  receive Internet traffic.

The issue  here is that  it is the  CE device which  has to ensure  that the
customer only gets the services he paid for, even though the CE device is on
the customer's premises  and is at least partially  managed by the customer.
I guess the SPs will need to say what they think about this.

>> each one has VPN service from that provider.

Jeremy> They could only do this by explicitly playing with the CE device and
Jeremy> the CE-PE interface, at a high security risk. This doesn't seem like
Jeremy> a very probable scenario. 

Well, whenever you try to steal something you incur a risk, but that doesn't
seem to make theft improbable.

>> Consider the case in  which half of the VPN's sites attach  to one SP and
>> half to another.  Now, what information  needs to be under the control of
>> what management systems?

Jeremy> SP1 will control all the security information and will provision all
Jeremy> CEs. SP1 will need to know which IP addresses SP2 will assign to the
Jeremy> CEs  that are  attached to  SP2 (I'm  talking about  the  'outer' IP
Jeremy> addresses used for the virtual interfaces).

I believe this is  a feasible model only if SP1 is  the VPN provider and SP2
is just providing Internet access.

---

From: [email-masked]
Date: Thu, 01 Aug 2002 18:06:34 +0200

> before and I want to be sure it is well understood.

doesn't "proper IPsec support" already implies the ability to work with
two routing and address spaces, as tunnel mode is part of IPsec ?

> routing.   That  is why  we  need  to think  of  there  being two  different

I'm not sure I understand.. If there is only one CE-PE link, the only
information that is needed is that all packets sent trough the virtual
interfaces need to be sent to the PE, this can be seen as a 'default
route' obtained via configuration, no ?

(I understand we can think of there being two different forwarding
tables, but I'm not sure we *need* to think of it like that ;-), but I
guess it's not that important, is it? As long as we agree that there is
VPN functionality needed on the CE... We'll make this point more
explicit in the draft.)

> would probably not be regarded as an advantage.

Noted.
 
> seem to make theft improbable.

:-)

But maybe paying for a car, and taking away its wheels to be able to
steal a bike is improbable ;-)

or maybe the SP will let you pay for a car and a bike even if you just
ask for a car...

> is just providing Internet access.

Agreed. And I don't think this model breaks the inter-AS case or the
Internet transparency.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 01 Aug 2002 13:13:04 -0400

Jeremy> doesn't "proper  IPsec support" already implies the  ability to work
Jeremy> with two routing and address spaces,

No, not at all.  Generally the tunnel endpoint addresses are within the same
address space as is used by the tunneled packets, or else one uses some sort
of  NAT   prevent  address  conflict.    (L2TP  tunneling  gives   you  more
independence  of address  space, because  the  tunneled packets  are not  IP
packets.) 

Jeremy> If there is only one CE-PE link, the only information that is needed
Jeremy> is that  all packets sent trough  the virtual interfaces  need to be
Jeremy> sent to the  PE, this can be seen as a  'default route' obtained via
Jeremy> configuration, no ? 

This is  not a default route,  but a static route  to the IP  address of the
remote tunnel endpoint.   Call this IP address X.  Suppose X  is also the IP
address of a system that is at the CE's site.  Now when the CE gets a packet
that is addressed to X, it doesn't want to send them according to the static
route, does it?

If  there's  only  one CE-PE  link,  I  guess  you  could require  that  the
encapsulated  packets be sent  to the  PE, regardless  of what  routing says
about  the path  to the  IP  address of  the tunnel's  remote endpoint.   Of
course, this breaks down if you allow multiple connectivity. 

You could simplify things a lot  by giving up the requirement that the CE/PE
links have addresses which may overlap the VPN address space.

Eric> I believe this is a feasible model only if SP1 is the VPN provider and
Eric> SP2 is just providing Internet access. 

Jeremy> Agreed.  And  I don't think this  model breaks the  inter-AS case or
Jeremy> the Internet transparency. 

This model is  okay technically.  Suppose though that  some enterprise wants
to hire SP A to construct a VPN  for its European sites, and to hire SP B to
construct a VPN  for its America sites, and  to have intra-VPN communication
between those two VPN pieces.  In your model, this couldn't be done, because
one of the SPs has to manage all the CEs.

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 1 Aug 2002 13:48:29 -0400

> one of the SPs has to manage all the CEs.

Between these two models, isn't the model where SP1 is the VPN provider and SP2
is providing Internet access the more likely scenario? Is there motivation for
SP A & SP B to interwork VPN service, given that SP A or SP B could provide
CE-based IP VPN to customer anywhere in the world?

regards
cheng-yin