Subject: RE: Request for Speaking Slot: draft-behringer-mpls-security-03.txt

From: "Sumit Garg" <[email-masked]>
Date: Wed, 6 Nov 2002 10:57:24 -0500

[snip]

> 
> LDP specifications says:
> 
> "An LSR is responsible for the consistency of the label 
> mappings it has distributed, and that its peers have these mappings"
> 
> Assuming Downstream Unsolicited operation, with Independent 
> control mapping, that is the scenario you have in mind, I 
> think. At a given moment, LSP link between B and C is 
> working, and B binds a legitimate label, and B send it to its 
> peers. B is since then responsible of the consistency. Should 
> the LSP link fail, and no LSP continuity can be locally 
> assured, there are withdrawal mechanisms to deal with this. 
> If they don't work, this is a case of malfunction, or poor 
> implementation.  

2 scearios: setup, teardown

setup

B has routing info, no binding from C, decides to send a map to A for D
(this is independent) D sends a binding to C and also sends to A (via
BGP).  C has yet not propagated this to B (whatever reasons).  A thinks
LSP is up.  We have the legitimate hole.

teardown

C withdraws from B. B is independent; doesn't withdraw from A.  Or worst
(even if ordered mode is used) is supposed to send a release to C before
sending the withdraw to A. Again a LSP hole iff only for the transient

Both these have nothing to do with malfunction/ sloppy implementation.
Nowhere have the bindings got in-consistent. the problem is that B and C
are agnostic of the VPN label.  A and D are agnostic of the LSP
end-to-end continuty.  Inherent problem with the protocol and its
multiple variations.  Work arounds exist but demand "intelligent"
config.  And that independent mode not be used.

These aren't the only holes. What if D had given explicit NULL to C.
And then given a VPN label to A. Traffic on link b/w B and C would have
the VPN as the inner label and the outer label would be link specific.
Now what label is C supposed to slap on before forwarding it to D?
Explicit NULL (remember end-of-stack bit MUST be set of explicit NULL)
So now D will interpret incoming VPN traffic as IP traffic !!

Soln: Don't use explicit NULL labels with VPNs.

[snip]

> 
> 
> My opinion is that only in case of malfunction this can 
> happen and that any reasonable implementation is able to deal 
> with this. And in any case, Ordered Control Mapping could be 
> a solution.
> 
ordered is a certainly a solution.

---

From: "Miguel Angel Chana (machana)" <[email-masked]>
Date: Wed, 6 Nov 2002 15:57:16 +0100

Hello:

Some comments in line:

> -----Original Message-----
> From: Sumit Garg [mailto:[email-masked]] 
> Sent: miércoles, 06 de noviembre de 2002 14:21
> To: Michael Behringer (mbehring); George Swallow (swallow); 
> 'Loa Andersson'
> Cc: [email-masked]
> Subject: RE: Request for Speaking Slot: 
> draft-behringer-mpls-security-03.txt
> 
> 
> Got only as far as page 6.
> 
> Some comments:
> --------------
> 
> Page 6, you write:
> 
> "Traffic separation is achieved by prepending VPN-specific 
> labels to the packets, so that a packet can also on the core 
> be identified as belonging to a specific VPN.  "
> 
> This assumes and implies that the core LSRs know that the 
> label is a VPN label; OR  more generically that there is 
> something special about a VPN label.  My understanding is 
> there isn't.  Labels are not looked at in any specific 
> context.  Infact with independent LSP setup, teardown and 
> local repair one can run into scenarios where the VPN traffic 
> doesn't stay so private. Example:
> 
> VPN1----A----B----C----D----VPN2
> 
> A and D are PEs and B and C and Ps. LSP from A to D comes up (or goes
> down) independently and for this example assume the LSP 
> segment between B and C is missing. A thinks there is a LSP

LDP specifications says:

"An LSR is responsible for the consistency of the label mappings it has distributed, and that its peers have these mappings"

Assuming Downstream Unsolicited operation, with Independent control mapping, that is the scenario you have in mind, I think. At a given moment, LSP link between B and C is working, and B binds a legitimate label, and B send it to its peers. B is since then responsible of the consistency. Should the LSP link fail, and no LSP continuity can be locally assured, there are withdrawal mechanisms to deal with this. If they don't work, this is a case of malfunction, or poor implementation.  

> to D (doesn't know of the hole between B and C) Traffic from 
> A goes to B with the outer label for the LSP to D and the 
> inner label for VPN sites connected at A and D
> 
> B doesn't have an outgoing label; does a pop of the outer 
> label and then as the end of stack bit is not set looks at 
> the inner label.  This label might have local significance at 
> B and so the traffic may ge switched to the wrong LSP and 
> therefore the wrong desitation.
> 
> This is a consequence of independent LSP setup.  End to end 
> LSP continuty cannot be guaranteed.  One possible option is 
> to set the opcode on the incoming lable on B as discard and 
> not pop and lookup.
> 
> Hope you get the idea.  And maybe the MPLS gurus can clarify my ideas?
>

My opinion is that only in case of malfunction this can happen and that any reasonable implementation is able to deal with this. And in any case, Ordered Control Mapping could be a solution.

> Some nits:
> ----------
> 
> Page number on page 1 is missing.
> 
> Page 2, after the bullet list there is a type ">From "
> 
> Doc formatting can be improved so that page numbers do fall 
> on end of page; most authors do it by embedding a form feed 
> (a CTRL-L).
> 
> 
> General observations:
> ---------------------
> 
> Don't see the point of this document wrt the WG.  What are we 
> trying to achieve?  Seems more like a white paper.  But then 
> these are my 2c.
>
> 
> /Sumit
> 
> > George, Loa,
> >
> > Recently I submitted an updated version of 
> > draft-behringer-mpls-security-03.txt. If you consider this work of 
> > interest to the MPLS WG, I would like to request a speaking slot at
> > the Atlanta
> > meeting.
> >
> > Thanks,
> > Michael
> >
> 
>