Subject: RE: VPLS model for L2VPN Framework document

From: [email-masked]
Date: Thu, 29 May 2003 17:33:31 +0100

Eric

Is the sole purpose of the untagged VPLS instance to carry service provider
BPDUs? If so there aren't any security concerns as all other untagged frames
can simply be dropped. However, I think the general term "untagged packets"
is misleading:

- a further distinct  VPLS instance is used to  carry the "untagged packets"
  of the emulated LAN.

Perhaps replacing "untagged packets" with "Service provider BPDUs" would
provide clarification on exactly what traffic can be carried using this VPLS
instance?

Richard

 > -----Original Message-----
 > From: Eric Rosen [mailto:[email-masked]]
 > Sent: 29 May 2003 15:29
 > To: Spencer,R,Richard,XGH5 R
 > Cc: [email-masked]
 > Subject: Re: VPLS model for L2VPN Framework document 
 > 
 > 
 > 
 > Richard> Is the  intention here  to create 1  VPLS control 
 > instance  (i) per
 > Richard> customer
 > 
 > No. 
 > 
 > Richard>  or (ii) per service provider network? 
 > 
 > Not necessarily limited to one per service provider network. 
 > 
 > However, this would be a deployment consideration, I think.
 > 
 > Richard> what  traffic  will be  carried  over  the  control 
 > VPLS?  Untagged
 > Richard> customer  frames or  untagged service  provider 
 > frames,  either way
 > Richard> this sounds like it may lead to security concerns.
 > 
 > I  think "untagged  service provider  frames" is  the 
 > answer.   What  is the
 > security concern? 
 >

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 29 May 2003 14:38:16 -0700

At 05:33 PM 5/29/2003 +0100, [email-masked] wrote:
>BPDUs?

Basically yes.

>If so there aren't any security concerns as all other untagged frames

Or we can say "SP untagged packets - e.g., BPDUs".

-Ali

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 29 May 2003 14:43:15 -0700

At 06:21 PM 5/29/2003 +0100, [email-masked] wrote:
>Eric,
>
>The security concern I was thinking of is the possibility of a customer
>injecting untagged frames into the SP network via a trunk port. In an
>Ethernet switch all untagged frames arriving on a trunk port can either be
>dropped or forwarded on the native VLAN (where the forward or drop action is
>dependant on the implementation and configuration). If untagged customer
>frames are not dropped by default, then access lists would have to be used
>to ensure untagged customer frames were not forwarded on the untagged VPLS
>instance. This is probably an implementation issue rather than something
>that would need to be defined in the draft.

The control VPLS is only for SP use and there shouldn't be any leak of 
customers' frames into this VPLS. If there is, then there is an intentional 
config error.

-Ali

>  > From: [email-masked] [mailto:[email-masked]]
>  > Sent: 29 May 2003 17:34
>  > To: [email-masked]
>  > Subject: RE: VPLS model for L2VPN Framework document
>  >
>  >
>  > Eric
>  >

---

From: [email-masked]
Date: Fri, 30 May 2003 08:47:43 +0100

Ali

 > Or we can say "SP untagged packets - e.g., BPDUs".

I still don't think that the above gives enough clarification. Packets are
only tagged between trunk ports. An operator may have access ports
connecting to different management networks that belong to different VLANs,
e.g. VLAN 100 for management application X, and VLAN 200 for management
application Y. Now, both of these access ports will receive untagged SP
packets, but they will be destined for different VLANs. Both sets of SP
untagged packets could not be sent over the same 'untagged VPLS instance' as
they belong to different VLANs.

Richard

---

From: Ali Sajassi <[email-masked]>
Date: Fri, 30 May 2003 10:28:54 -0700

>they belong to different VLANs.

If the access ports are .1q access ports, then bridge would only see tagged 
traffic from these two ports. If they are not .1q access ports, then the 
bridge can not differentiate between them and it gets sent over the control 
VPLS instance. Anyway, if we want to limit the control VPLS instance to 
only BPDUs, then we can state it as such; however, if we want to allow 
other control/management frames over it, then we don't need to be that 
explicit.

-Ali

-Ali