Subject: Re: [mpls-tp] Potential per-platform label space security issue

From: Maarten Vissers <[email-masked]>
Date: Mon, 02 Feb 2009 11:40:42 +0100

Francesco,

It is possible to use per-platform label space for PWs as long as this is
combined with "Ingress Filtering". I.e. when a packet with e.g. PW label
1000 is received via LSP #A the packet is accepted, but when a packet with
this label 1000 is received via a LSP #B, then this packet is filtered
(discarded).

If such Ingress Filtering is not possible and if we can't have per-interface
(i.e. per-section, per-LSP) PW label space, then we should list this as a
security risk.

Regards,
Maarten

-----Original Message-----
From: Francesco Fondelli [mailto:[email-masked]] 
Sent: donderdag 29 januari 2009 17:40
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Potential per-platform label space security issue

On Thu, Jan 29, 2009 at 5:14 PM,  <[email-masked]> wrote:
> IMO we should only use per interface labels in MPLS-TP.  regards, Neil

Agree, if LSP == connection, you have no choice.  A couple of notes
though:

a) Probably, there are some LSRs out there that do not support per
   interface label space.

b) The PW label MUST be allocated from the per-platform
   label space [RFC 4447].

c) Not sure if RFC 3031 imposes per interface label space
   support (I think it doesn't).

Ciao
FF

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Francesco Fondelli <[email-masked]>
Date: Mon, 2 Feb 2009 14:53:42 +0100

> Francesco,

Hi Maarten,

> this label 1000 is received via a LSP #B, then this packet is filtered

You can always build a box so that it can filter on whatever you
want.  However...

The PWE3 framework is based on the concept that "We do not presuppose
that PE2 will even be able to determine the MPLS tunnel through which
a received packet was transmitted" [RFC 4447].  PWE3 Data/control/management
planes are designed with this concept in mind.

Once upon a time there was a "strict VS loose" debate, "In strict mode,
only VC carried inside known in advance tunnels or interfaces are
accepted" [draft-ietf-pwe3-pw-mpls-mib-00], the strict mode
was there mainly for security reasons "bringing better security and
better miss-configuration error immunity" [draft-ietf-pwe3-pw-mpls-mib-00],
Now-day [draft-ietf-pwe3-pw-mpls-mib-14] only the loose mode exists.
The strict mode is (was) almost what you suggest Maarten (I don't remember
why it was removed, we should ask pwe3 people).

That said, IMHO the only sane way to behave "transport" is to configure
all boxes in your network to allocate LSP labels from the per-interface
label space *and* configure LSPs (all of them) as bidi-co-routed so the
"PW inbound tunnel indetermination problem" is obviously a no-problem.

> (i.e. per-section, per-LSP) PW label space, then we should list this as amart
> security risk.

I agree with Neil wrt this point.  IMHO is not (only) a matter of security,
is also about "transport" (whatever this mean :-)).

> Maarten

thanks
Ciao
FF