Subject: Re: [mpls-tp] [mpls] IPR Disclosure: Alcatel Lucent's Statement about IPR related to draft-ietf-mpls-tp-oam-framework-07

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 6 Aug 2010 09:23:27 +0300

Curtis, and all,
I would like to point to my previous statements regarding applicability (or, rather, NON-applicability) 
of label stacking as a method to monitor LSP segments on the MPLS-TP list.
This seems to be appropriate since:
- Neither the original IR disclosure message nor your comments to it have been sent to the MPLS-TP list
- The patent describes yet another technique for path segment monitoring.

You can find two related threads - "Problems with SPNE as the path segment monitoring tool in MPLS-TP" and 
"Query regarding usage of MPLS-TP SPME" in the list archive at http://www.ietf.org/mail-archive/web/mpls-tp/current/maillist.html. 
These two threads taken together count, as of today, 60+ messages, and include an interesting discussion regarding
applicability of Y.1731-like OAM reference model to MPLS-TP.

There have been attempts to define segment path monitoring based on TTL expiration 
(e.g., http://tools.ietf.org/html/draft-zhang-mpls-tp-path-segment-monitoring-00 ).
If we can reach consensus on this approach, two things would happen:
- The OAM Framework draft would have to be re-hashed yet again. (Note that the current reference model that does not allow
  MIPs to initiate OAM messages would have to be scrapped as part of this re-hash)
- The IPR claims in the patent to which you refer could hopefully (I am not a patent lawyer, so it is very easy to be wrong here) 
   safely ignored by the implementers of this approach.

My 2c,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Curtis Villamizar [[email-masked]]
Sent: Friday, August 06, 2010 2:12 AM
To: IETF Secretariat
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] IPR Disclosure: Alcatel Lucent's Statement about IPR        related to draft-ietf-mpls-tp-oam-framework-07

In message <[email-masked]>
IETF Secretariat writes:
>
> Dear Martin Vigoureux, Dinesh Mohan, Nurit Sprecher, Ben
> Niven-Jenkins, Huub Helvoort, Yaacov Weingarten, Lieven Levrau,
> Annamaria Fulignoli, Rolf Winter, David Allan, Italo Busi, Enrique
> Hernandez-Valencia, Vincenzo Sestito:
>
> An IPR disclosure that pertains to your Internet-Draft entitled
> "MPLS-TP OAM Framework" (draft-ietf-mpls-tp-oam-framework) was
> submitted to the IETF Secretariat on 2010-08-05 and has been posted on
> the "IETF Page of Intellectual Property Rights Disclosures"
> (https://datatracker.ietf.org/ipr/1369/). The title of the IPR
> disclosure is "Alcatel Lucent's Statement about IPR related to
> draft-ietf-mpls-tp-oam-framework-07."
>
> The IETF Secretariat

The patent (Europe's copy) is in PDF form at:

  https://data.epo.org/publication-server/document?PN=EP1753169%20EP%201753169&iDocId=6984847&iPosition=1&iFormat=0

The title is:

   Method, network node and MPLS network for monitoring a tandem
   connection in a MPLS telecommunication network

It applies only to a method for handling a tandem connection and
applies to a technique which puts a special value in the label or EXP
field and does not use label stacking as the means to support the
tandem connection.

    [0040] However; according to the present invention, differently
    from the label stacking according to the above mentioned RFC3032,
    the input node of the tandem con- nection inserts such a tandem
    connection header after the already present switching header H1,
    H2, ..., H8.

The above paragraph specifically cites this limitation of the patent.
As long at tandem connections continue to use label stacking as per
MPLS hierarchy and don't use a special value in the label or EXP field
to indicate a tandem connection, which is in no way suggested in
draft-ietf-mpls-tp-oam-framework-07, then this patent does not seem to
be applicable.

The claims start on page 8.  In my reading of
draft-ietf-mpls-tp-oam-framework-07 I did not find anything that
resembled inserting a tandem connection header with some predefined
label or EXP value after the switching header.
draft-ietf-mpls-tp-oam-framework-07 is using label stacking as per
RFC3032, which is excluded from the patent (as it would invalidate it,
given that label stacking in RFC3032 predated any patent application.

The GAL and ACH identify an OAM flow, they do not identify a tandem
connection, which seems to be the entire basis of the patent.
Otherwise it is label stacking as we've always known it.

I am not a lawyer nor am I a certified patent examiner.  This is just
an opinion based on my technical knowledge in this area.  Please get a
lawyer to confirm this opinion.

Maybe Italo or someone else at Alcatel Lucent can explain why anyone
thought this patent was applicable to
draft-ietf-mpls-tp-oam-framework-07 since the IPR statement doesn't
even point to the one and only section of the draft related to tandom
connections.

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

---

From: [email-masked]
Date: Sat, 7 Aug 2010 17:45:19 +0800

Sasha, and all

As an author of this document: 
http://tools.ietf.org/html/draft-zhang-mpls-tp-path-segment-monitoring-00, 
I really think the approach
based on TTL expiration can meet the requirements of SPME monitoring.

If we can reach consensus on it, at the same time, keep the definition of 
MEP/MIP function in MPLS-TP 
(not re-hash the OAM Framework draft ), what needs to do is just to define 
the MEP function of SPME.

IMHO, it is easy to add it in the document, 
http://tools.ietf.org/html/draft-ietf-mpls-tp-identifiers-02, and the 
format maybe like this:Src-Global_ID::Src-Node_ID::Src-Tunnel_Num::LSP_Num 
::SPME-Global_ID::SPME-Node_ID

B.R.

Fei

Alexander Vainshtein <[email-masked]> 
发件人:  [email-masked]
2010-08-06 14:23

收件人
"[email-masked]" <[email-masked]>
抄送
MPLS TP <[email-masked]>
主题
Re: [mpls-tp] [mpls] IPR Disclosure: Alcatel Lucent's Statement about IPR 
related to draft-ietf-mpls-tp-oam-framework-07

Curtis, and all,
I would like to point to my previous statements regarding applicability 
(or, rather, NON-applicability) 
of label stacking as a method to monitor LSP segments on the MPLS-TP list.
This seems to be appropriate since:
- Neither the original IR disclosure message nor your comments to it have 
been sent to the MPLS-TP list
- The patent describes yet another technique for path segment monitoring.

You can find two related threads - "Problems with SPNE as the path segment 
monitoring tool in MPLS-TP" and 
"Query regarding usage of MPLS-TP SPME" in the list archive at 
http://www.ietf.org/mail-archive/web/mpls-tp/current/maillist.html. 
These two threads taken together count, as of today, 60+ messages, and 
include an interesting discussion regarding
applicability of Y.1731-like OAM reference model to MPLS-TP.

There have been attempts to define segment path monitoring based on TTL 
expiration 
(e.g., 
http://tools.ietf.org/html/draft-zhang-mpls-tp-path-segment-monitoring-00 
).
If we can reach consensus on this approach, two things would happen:
- The OAM Framework draft would have to be re-hashed yet again. (Note that 
the current reference model that does not allow
  MIPs to initiate OAM messages would have to be scrapped as part of this 
re-hash)
- The IPR claims in the patent to which you refer could hopefully (I am 
not a patent lawyer, so it is very easy to be wrong here) 
   safely ignored by the implementers of this approach.

My 2c,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Curtis 
Villamizar [[email-masked]]
Sent: Friday, August 06, 2010 2:12 AM
To: IETF Secretariat
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]; [email-masked]; 
[email-masked]; [email-masked]; 
[email-masked]; [email-masked]; 
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] IPR Disclosure: Alcatel Lucent's Statement about IPR   
  related to draft-ietf-mpls-tp-oam-framework-07

The title is:

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 8 Aug 2010 07:42:02 +0300

Fei,
Lots of thanks for a prompt response.

I agree with you that a TTL-based technique can be used for segment monitoring in MPLS-TP.

I do not see, however, how this kind of technique can be added without re-hashing the MPLS-TP OAM Framework document.

This document follows Y.1731 concepts with its differentiation between MEPs and MIPs, ME Levels etc. 

Within this model MIPs cannot initiate OAM messages, and Y.1731-compliant MEPs cannot be located
in the transit nodes of an LSP,. Hence you need a new LSP spanning just the monitored segment in 
order to comply with this model.

You can find more detail in the threads to which I have referred, including some comments from Dave Allan and Ben Niven-Jenkins.

The root cause of the problem is neither lack of tools in MPLS nor complexity of their adaptation to the
MPLS-TP environment. It is, IMHO, the direct consequence of attempts to impose a reference model that
does not match the reality of the MPLS data plane on MPLS-TP. Hence the references to "future
MPLS-TP equipment" (that would operate a different data plane) that you can also find in these threads. 

Hopefully this clarifies my position.

My 2c,
     Sasha

From: [email-masked] [[email-masked]]
Sent: Saturday, August 07, 2010 12:45 PM
To: Alexander Vainshtein
Cc: [email-masked]; MPLS TP; [email-masked]
Subject: Re: [mpls-tp] [mpls] IPR Disclosure: Alcatel Lucent's Statement about IPR related to draft-ietf-mpls-tp-oam-framework-07

Sasha, and all 

As an author of this document: http://tools.ietf.org/html/draft-zhang-mpls-tp-path-segment-monitoring-00, I really think the approach 
based on TTL expiration can meet the requirements of SPME monitoring. 

If we can reach consensus on it, at the same time, keep the definition of MEP/MIP function in MPLS-TP 
(not re-hash the OAM Framework draft ), what needs to do is just to define the MEP function of SPME. 

IMHO, it is easy to add it in the document, http://tools.ietf.org/html/draft-ietf-mpls-tp-identifiers-02, and the format maybe like this:Src-Global_ID::Src-Node_ID::Src-Tunnel_Num::LSP_Num ::SPME-Global_ID::SPME-Node_ID 

B.R. 

Fei 

Alexander Vainshtein <[email-masked]> 
发件人:  [email-masked] 
2010-08-06 14:23 收件人"[email-masked]" <[email-masked]> 
抄送MPLS TP <[email-masked]> 
主题Re: [mpls-tp] [mpls] IPR Disclosure: Alcatel Lucent's Statement        about IPR        related to draft-ietf-mpls-tp-oam-framework-07

Curtis, and all,

My 2c,
    Sasha

The title is:

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 09 Aug 2010 13:18:41 +0200

Sasha,

MEP functions secure the inner domain in addition to sourcing and sinking
the OAM for this domain. The MEP source function prevents that an intruder
can query the nodes inside the domain. A MIP does not have this capability.

In Ethernet every ingress frame is checked if it is a potential intruder
frame by means of checking for the following characteristics:
1) is it an OAM frame
2) is its MEG level the same or a lower level than the MEP source's MEG
level
And every egress frame is checked if it is potentially leaking out the
domain by means of checking
1) is it an OAM frame
2) is its MEG level the same or a lower level than the MEP source's MEG
level.

In MPLS-TP this security aspect is designed by label stacking every incoming
data/OAM packet.

If you want to replace the MEP functions by extended MIP functions, then the
MIP functions at the edge of the MEG have to perform the security filtering
of ingressing and egressing packets. This implies that every incoming packet
has to be checked if it includes identifiers that would result in a response
from inside the domain, and every domain egressing packet would have to be
checked if it is leaking out. 

Domain edges typically are not aware of the identifiers that are active in
inner segments of their domain, so checking would be almost impossible,
creating a security risk.

An alternative for ingress security filtering for p2p LSPs/PWs is to check
the TTL value in the ingressing packet by the MIP at the boundary of the
MEG; if the value (e.g. 7) is less then the number of hops to the end of
this MEG (e.g. 10), then discard this packet at the ingress MIP. Security
filtering using TTL value at the egress MIP of the MEG is however difficult.
Security filtering at the ingress MIP of a MEG for a p2mp LSP/PW is not
possible, as the number of hops to the different MEG endpoints will vary.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Vainshtein
Sent: zondag 8 augustus 2010 6:42
To: [email-masked]
Cc: MPLS TP
Subject: Re: [mpls-tp] [mpls] IPR Disclosure: Alcatel Lucent's Statement
about IPR related to draft-ietf-mpls-tp-oam-framework-07

Fei,

I agree with you that a TTL-based technique can be used for segment
monitoring in MPLS-TP.

I do not see, however, how this kind of technique can be added without
re-hashing the MPLS-TP OAM Framework document.

This document follows Y.1731 concepts with its differentiation between MEPs
and MIPs, ME Levels etc. 

Within this model MIPs cannot initiate OAM messages, and Y.1731-compliant
MEPs cannot be located in the transit nodes of an LSP,. Hence you need a new
LSP spanning just the monitored segment in order to comply with this model.

You can find more detail in the threads to which I have referred, including
some comments from Dave Allan and Ben Niven-Jenkins.

The root cause of the problem is neither lack of tools in MPLS nor
complexity of their adaptation to the MPLS-TP environment. It is, IMHO, the
direct consequence of attempts to impose a reference model that does not
match the reality of the MPLS data plane on MPLS-TP. Hence the references to
"future MPLS-TP equipment" (that would operate a different data plane) that
you can also find in these threads. 

My 2c,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 9 Aug 2010 14:58:30 +0300

Maarten,
Lots of thanks for presenting your position.

I am not a network security expert and do not know if OAM-based intrusion should be considered a real security risk.
But OAM mechanisms designed by the IETF employ dedicated security mechanisms, and these mechanisms are reviewed by the network security experts
(Security Area Directors) as part of the normal IETF process. From personal experience I can tell you that getting their approval is highly
non-trivial. 

IMHO you could take a look at the Security Considerations sections in RFC 4379 (LSP Ping) and RFC 5880 (BFD) as the examples of successful 
(from the IETF process view) analysis of security threats and techniques proposed for their mitigation.

I cannot say whether these mechanisms are sufficient to protect MPLS-TP networks from "OAM intrusion attacks". 
Some OAM-related aspects of MPLS-TP (GAL/G-Ach, MEP/MIP assignment, loopback) have been identified as MPLS-TP specific
areas of potential attacks by the team working on the MPLS-TP Security Framework draft, and I expect some answers will be available soon.

On the other hand, I doubt if the security mechanisms you have described are sufficient. 

On a somewhat related topic, I'd say that lack of properly defined security mechanisms in draft-bhh is yet another
factor for NOT advancing it (at least until its Security Considerations sections changes from the form it consistently had
in all draft versions from -00 to -05 - "to be added in the future version" - to something a bit more specific).

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Monday, August 09, 2010 2:19 PM
To: Alexander Vainshtein; [email-masked]
Cc: 'MPLS TP'
Subject: RE: [mpls-tp] [mpls] IPR Disclosure: Alcatel Lucent's Statement about IPR related to draft-ietf-mpls-tp-oam-framework-07

Sasha,

Regards,
Maarten

-----Original Message-----

Fei,

My 2c,
     Sasha

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 09 Aug 2010 15:05:53 +0200

Sasha,

Y.1731/802.1ag Ethernet OAM is considered to be secure. Using a similar
mechanism for MPLS-TP should also make MPLS-TP OAM secure within the
intended transport network deployment. The -bhh draft reuses the Ethernet
OAM security mechanism, so it will be secure within the intended transport
network deployment. I.e. there is no need to make it more complex.

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: maandag 9 augustus 2010 13:59
To: Maarten Vissers
Cc: 'MPLS TP'; [email-masked]
Subject: MEPs, MIPs and Security (was IPR Disclosure: Alcatel Lucent's
Statement about IPR related to draft-ietf-mpls-tp-oam-framework-07)

Maarten,

I am not a network security expert and do not know if OAM-based intrusion
should be considered a real security risk.
But OAM mechanisms designed by the IETF employ dedicated security
mechanisms, and these mechanisms are reviewed by the network security
experts (Security Area Directors) as part of the normal IETF process. From
personal experience I can tell you that getting their approval is highly
non-trivial. 

IMHO you could take a look at the Security Considerations sections in RFC
4379 (LSP Ping) and RFC 5880 (BFD) as the examples of successful (from the
IETF process view) analysis of security threats and techniques proposed for
their mitigation.

I cannot say whether these mechanisms are sufficient to protect MPLS-TP
networks from "OAM intrusion attacks". 
Some OAM-related aspects of MPLS-TP (GAL/G-Ach, MEP/MIP assignment,
loopback) have been identified as MPLS-TP specific areas of potential
attacks by the team working on the MPLS-TP Security Framework draft, and I
expect some answers will be available soon.

On the other hand, I doubt if the security mechanisms you have described are
sufficient. 

On a somewhat related topic, I'd say that lack of properly defined security
mechanisms in draft-bhh is yet another factor for NOT advancing it (at least
until its Security Considerations sections changes from the form it
consistently had in all draft versions from -00 to -05 - "to be added in the
future version" - to something a bit more specific).

Regards,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 9 Aug 2010 17:18:53 +0300

Maarten,
Lots of thanks for an amazingly prompt response.
Please see inline below. 

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Monday, August 09, 2010 4:06 PM
To: Alexander Vainshtein
Cc: 'MPLS TP'
Subject: RE: MEPs, MIPs and Security (was IPR Disclosure: Alcatel Lucent's Statement about IPR related to draft-ietf-mpls-tp-oam-framework-07)

Sasha,

Y.1731/802.1ag Ethernet OAM is considered to be secure. 
[[[Sasha]]] I've looked up security considerations in 802.1ag, and I'd like to note that they are present a picture
that is quite different from one you're presenting. In fact, 802.1ag includes two security-related components:
- Using security features of SNMPv3 to prevent unauthorized access to devices (including access to
  MEPs and MIPs). This is a very generic recommendation that is equally applicable to all situations dealing with
  SNMP-based management. In fact, IETF has been, for quite some time, including similar recommendations in all RFCs
  that define MIBs
- Using MAC security (802.1AE) to prevent DoS attacks on MEPs and MIPs. This component is quite specific and includes
  a recommendation to locate MEPs and MIPS above the MAC security shim (see section 22.1.8). My interpretation of this
  recommendation is that
  (a) Per se, 802.1ag is not sufficiently secure
  (b) It can be secured using security mechanisms that are specific for Ethernet bridges.
As for Y.1731, scan of the version that can access (02/2008) did not provide any hits for the string "secur". 

Using a similar mechanism for MPLS-TP should also make MPLS-TP OAM secure within the
intended transport network deployment. 
[[[Sasha]]] I am not aware of any analogs of 802.1AE for MPLS or MPLS-TP. Did I miss something?

The -bhh draft reuses the Ethernet OAM security mechanism
[[[Sasha]]] Could you please elaborate? Do you propose using MAC security in MPLS-TP? Or something else?
, so it will be secure within the intended transport
network deployment. I.e. there is no need to make it more complex.

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: maandag 9 augustus 2010 13:59
To: Maarten Vissers
Cc: 'MPLS TP'; [email-masked]
Subject: MEPs, MIPs and Security (was IPR Disclosure: Alcatel Lucent's

Maarten,

Regards,
     Sasha

---

From: <[email-masked]>
Date: Mon, 9 Aug 2010 15:34:38 +0100

Sasha,

Some comments on this.

co-ps mode networks based on label swapping do generate security
concerns that are additional to conscientious/malicious security attacks
simply due to the fact that HW/SW defects can result in traffic being
unintentionally replicated and sent to the wrong place.  Accidental
misconfiguration can also result in traffic being set to the wrong
place.

This is why one has to run a CV flow with the absolute SA on each
connection in a co-ps mode network based on label swapping if one wants
to be assured of detecting such leaking/misdirected traffic.

Please also note that with label stacking we can have mixes of MPLS-TP
layers, MPLS-TP sublayers and a PW layers (all having different
addressing instances).....so one can have a rich set of potential
misconnectivity combinations to consider.

Now the above is largely predicated on a client/server view of the world
in MPLS-TP (which as noted is complicated due to sublayering and having
PWs, both of which should not exist if MPLS-TP was providing a proper
transport network role).  However, one can make the security problem
even more acute if one consciously allows/promotes E-NNIs peering
between different parties and one implements multiple TCM OAM sublayers.
Now one has the addition security concerns Maarten notes where one
requires active filtering of OAM messages at TCM level boundaries.

Of course, one could observe here that since MPLS-TP is not a TOS layer
network it has no technical need for E-NNIs at all, and so this is no
reason to promote TCM.  In other words, why create a problem for oneself
'just because one can' when it is technically unnecessary to do so?

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
> Sent: 09 August 2010 12:59
> To: Maarten Vissers
> Cc: 'MPLS TP'
> Subject: [mpls-tp] MEPs, MIPs and Security (was IPR 
> Disclosure: Alcatel Lucent's Statement about IPR related to 
> draft-ietf-mpls-tp-oam-framework-07)
> 
> Maarten,
> I am not a network security expert and do not know if 
> OAM-based intrusion should be considered a real security risk.
> But OAM mechanisms designed by the IETF employ dedicated 
> security mechanisms, and these mechanisms are reviewed by the 
> network security experts (Security Area Directors) as part of 
> the normal IETF process. From personal experience I can tell 
> you that getting their approval is highly non-trivial. 
> 
> IMHO you could take a look at the Security Considerations 
> sections in RFC 4379 (LSP Ping) and RFC 5880 (BFD) as the 
> examples of successful (from the IETF process view) analysis 
> of security threats and techniques proposed for their mitigation.
> 
> I cannot say whether these mechanisms are sufficient to 
> protect MPLS-TP networks from "OAM intrusion attacks". 
> Some OAM-related aspects of MPLS-TP (GAL/G-Ach, MEP/MIP 
> assignment, loopback) have been identified as MPLS-TP 
> specific areas of potential attacks by the team working on 
> the MPLS-TP Security Framework draft, and I expect some 
> answers will be available soon.
> 
> On a somewhat related topic, I'd say that lack of properly 
> defined security mechanisms in draft-bhh is yet another 
> factor for NOT advancing it (at least until its Security 
> Considerations sections changes from the form it consistently 
> had in all draft versions from -00 to -05 - "to be added in 
> the future version" - to something a bit more specific).
> 
> Regards,
>      Sasha
> 
> Subject: RE: [mpls-tp] [mpls] IPR Disclosure: Alcatel 
> Lucent's Statement about IPR related to 
> draft-ietf-mpls-tp-oam-framework-07
> 
> Sasha,
> 
> MEP functions secure the inner domain in addition to sourcing 
> and sinking the OAM for this domain. The MEP source function 
> prevents that an intruder can query the nodes inside the 
> domain. A MIP does not have this capability.
> 
> In Ethernet every ingress frame is checked if it is a 
> potential intruder frame by means of checking for the 
> following characteristics:
> 1) is it an OAM frame
> 2) is its MEG level the same or a lower level than the MEP 
> source's MEG level And every egress frame is checked if it is 
> potentially leaking out the domain by means of checking
> 1) is it an OAM frame
> 2) is its MEG level the same or a lower level than the MEP 
> source's MEG level.
> 
> In MPLS-TP this security aspect is designed by label stacking 
> every incoming data/OAM packet.
> 
> If you want to replace the MEP functions by extended MIP 
> functions, then the MIP functions at the edge of the MEG have 
> to perform the security filtering of ingressing and egressing 
> packets. This implies that every incoming packet has to be 
> checked if it includes identifiers that would result in a 
> response from inside the domain, and every domain egressing 
> packet would have to be checked if it is leaking out. 
> 
> Domain edges typically are not aware of the identifiers that 
> are active in inner segments of their domain, so checking 
> would be almost impossible, creating a security risk.
> 
> An alternative for ingress security filtering for p2p 
> LSPs/PWs is to check the TTL value in the ingressing packet 
> by the MIP at the boundary of the MEG; if the value (e.g. 7) 
> is less then the number of hops to the end of this MEG (e.g. 
> 10), then discard this packet at the ingress MIP. Security 
> Security filtering at the ingress MIP of a MEG for a p2mp 
> LSP/PW is not possible, as the number of hops to the 
> different MEG endpoints will vary.
> 
> Regards,
> Maarten
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
> Subject: Re: [mpls-tp] [mpls] IPR Disclosure: Alcatel 
> Lucent's Statement about IPR related to 
> draft-ietf-mpls-tp-oam-framework-07
> 
> Fei,
> I do not see, however, how this kind of technique can be 
> added without re-hashing the MPLS-TP OAM Framework document.
> 
> This document follows Y.1731 concepts with its 
> differentiation between MEPs and MIPs, ME Levels etc. 
> 
> Within this model MIPs cannot initiate OAM messages, and 
> Y.1731-compliant MEPs cannot be located in the transit nodes 
> of an LSP,. Hence you need a new LSP spanning just the 
> monitored segment in order to comply with this model.
> 
> You can find more detail in the threads to which I have 
> referred, including some comments from Dave Allan and Ben 
> Niven-Jenkins.
> 
> The root cause of the problem is neither lack of tools in 
> MPLS nor complexity of their adaptation to the MPLS-TP 
> environment. It is, IMHO, the direct consequence of attempts 
> to impose a reference model that does not match the reality 
> of the MPLS data plane on MPLS-TP. Hence the references to 
> "future MPLS-TP equipment" (that would operate a different 
> data plane) that you can also find in these threads. 
>

---

From: <[email-masked]>
Date: Mon, 9 Aug 2010 16:20:18 +0100

Sasha,

Please do not forget these points:
-	Ethernet is a cl-ps mode technology...in a cl-ps mode technology
there are no short-cuts possible on labelling in the traffic units (ie
full SA, DA, PID labels must be included) as there is no (parent)
connection to carry source information...more specifically we do NOT use
label-swapping here.
-	we can make a co-ps mode technology also robust to security
compromises due to HW/SW defects creating unintentional traffic
replication/misdirection if we do not use label-swapping.

So we do not have exactly the same scenarios in Ethernet and MPLS-TP.

regards, neil 

> Sent: 09 August 2010 15:19
> To: Maarten Vissers
> Cc: 'MPLS TP'
> Subject: Re: [mpls-tp] MEPs, MIPs and Security (was IPR 
> Subject: RE: MEPs, MIPs and Security (was IPR Disclosure: 
> Alcatel Lucent's Statement about IPR related to 
> [[[Sasha]]] I've looked up security considerations in 
> 802.1ag, and I'd like to note that they are present a picture 
> that is quite different from one you're presenting. In fact, 
> 802.1ag includes two security-related components:
>   MEPs and MIPs). This is a very generic recommendation that 
> is equally applicable to all situations dealing with
>   SNMP-based management. In fact, IETF has been, for quite 
> some time, including similar recommendations in all RFCs
>   that define MIBs
> - Using MAC security (802.1AE) to prevent DoS attacks on MEPs 
> and MIPs. This component is quite specific and includes
>   a recommendation to locate MEPs and MIPS above the MAC 
> security shim (see section 22.1.8). My interpretation of this
>   recommendation is that
> As for Y.1731, scan of the version that can access (02/2008) 
> did not provide any hits for the string "secur". 
> 
> Using a similar mechanism for MPLS-TP should also make 
> MPLS-TP OAM secure within the intended transport network deployment. 
> [[[Sasha]]] Could you please elaborate? Do you propose using 
> MAC security in MPLS-TP? Or something else?
> , so it will be secure within the intended transport network 
> deployment. I.e. there is no need to make it more complex.
> 
> Regards,
> Maarten
> 
> Subject: MEPs, MIPs and Security (was IPR Disclosure: Alcatel 
> sections in RFC
> 4379 (LSP Ping) and RFC 5880 (BFD) as the examples of 
> successful (from the IETF process view) analysis of security 
> threats and techniques proposed for their mitigation.
> 
> loopback) have been identified as MPLS-TP specific areas of 
> potential attacks by the team working on the MPLS-TP Security 
> Framework draft, and I expect some answers will be available soon.
>

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 09 Aug 2010 12:00:11 -0400

Sasha,

In message <[email-masked]>
Alexander Vainshtein writes:
> Y.1731-compliant MEPs cannot be located in the transit nodes of an
> LSP,. Hence you need a new LSP spanning just the monitored segment in
> You can find more detail in the threads to which I have referred,
> including some comments from Dave Allan and Ben Niven-Jenkins.

Which is nicely summarized by Dave:

  Venkatesan>  Can SPME for LSP/PW always be achieved in the form of
  Venkatesan>  label stacking on top of E2E LSP/PW?

  Dave>  With the understanding that SPMEs cannot overlap.....

All existing documents that have gone to RFC or through last call have
pointed toward label stacking as the means to support SPME.  I see no
good reason to change this.

> complexity of their adaptation to the MPLS-TP environment. It is,
> IMHO, the direct consequence of attempts to impose a reference model
> that does not match the reality of the MPLS data plane on
> MPLS-TP. Hence the references to "future MPLS-TP equipment" (that
> would operate a different data plane) that you can also find in these
> threads.

All existing documents that have gone to RFC indicate that there will
be no change to the data plane.  Therefore the opinion that there will
be a future data plane does not match the direction that MPLS-TP is
currently taking.  Anyone who thinks that there will be a future data
plane that is changed to accommodate a different method of supporting
SPME is (IMO) mistaken.

> Hopefully this clarifies my position.

And a valuable 2c they are.

Regards,

Curtis

> ������:  [email-masked] 
> 2010-08-06 14:23 �ռ���"[email-masked]" <[email-masked]> 
> ����MPLS TP <[email-masked]> 
> ����Re: [mpls-tp] [mpls] IPR Disclosure: Alcatel Lucent's Statement        about IPR        related to draft-ietf-mpls-tp-oam-framework-07
>  
>  
>  
>  
>  
>  
>  
> Curtis, and all,

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 09 Aug 2010 13:13:22 -0400

In message <[email-masked]>
> 2) is its MEG level the same or a lower level than the MEP source's MEG

Just a nit.  This is a sanity check not a security mechanism.

> In MPLS-TP this security aspect is designed by label stacking every incoming

This too is not a security mechanism.  It is harder to inject a packet
within a lower level LSP but compromise of any node along the path
would allow it.

> checked if it is leaking out. 

Only at administrative boundaries is this needed.  It is a lot like
packet filtering at administrative boundaries today where you don't
allow source addresses from your NOC or infrastructure to come from
outside the network.

> creating a security risk.

It is done today.  IP has route aggregation which cannot be applied to
Ethernet MAC addresses.  Typically it is a one or two prefix route
filter.  This is done today by most or all major Internet providers.

The best answer might be to use addressing in the control and
manangement plane (and OAM plane if you don't count that control
plane) which support route aggregation.  There is such a thing (IP)
which is available now and in widespread use with MPLS.

The fallback in these schemes is a strong (crypto) authentication but
that does not protect against certain demial of service attacks that
the filtering can take care of (at the edges only).

> possible, as the number of hops to the different MEG endpoints will vary.

This "alternative" doesn't sound like a good idea (IMO).

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 09 Aug 2010 13:18:45 -0400

In message <[email-masked]>
Alexander Vainshtein writes:
> I am not a network security expert and do not know if OAM-based
> intrusion should be considered a real security risk.  

It is a real risk.  Physical breach can occur.  Sloppy administrative
practices can result in a breach at a site.

> experts (Security Area Directors) as part of the normal IETF
> process. From personal experience I can tell you that getting their
> approval is highly non-trivial.

It will have to be documented.

> IMHO you could take a look at the Security Considerations sections in
> RFC 4379 (LSP Ping) and RFC 5880 (BFD) as the examples of successful
> (from the IETF process view) analysis of security threats and
> techniques proposed for their mitigation.
>  
> I cannot say whether these mechanisms are sufficient to protect
> MPLS-TP networks from "OAM intrusion attacks".  Some OAM-related
> aspects of MPLS-TP (GAL/G-Ach, MEP/MIP assignment, loopback) have been
> identified as MPLS-TP specific areas of potential attacks by the team
> working on the MPLS-TP Security Framework draft, and I expect some

I agree.  Filtering techniques are valuable at a domain border.  The
TTL ideas may not be valuable.

> On a somewhat related topic, I'd say that lack of properly defined
> security mechanisms in draft-bhh is yet another factor for NOT
> advancing it (at least until its Security Considerations sections
> changes from the form it consistently had in all draft versions from
> -00 to -05 - "to be added in the future version" - to something a bit
> more specific).
>  
> Regards,
>      Sasha

There are plenty of reasons not to advance draft-bhh and this may be
the least of them.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 09 Aug 2010 13:52:54 -0400

In message <[email-masked]>
> network deployment. I.e. there is no need to make it more complex.

Considered secure by who?  Certainly not by the US DOD or anyone that
really knows anything at all about security.

OTOH - Some people consider a firewall front ending a bunch of windows
PCs to be secure.  The number of corporate subnets repeatedly infected
by viruses indicates otherwise.  Still some people consider it secure.

In the security world there is no such thing as a secure channel
except one that is encrypted end to end and that is still subject to a
denial of service attack from the middle (whether it is radio, copper,
fiber, or avian based transmission media).

That said, OSPF-TE, ISIS-TE, RSVP-TE support authentication of
exchange of information but lack authentication of advertisement
originators (or signaling ingress and egress).

Strong authenciation provides a secure channel (with snooping
exposure) and filtering on edges helps with denial of service attacks
from outside.  TTL does not provide protection from the layers above,
except in the case of one hop GTSM (and GTSM does not cover physical
media or lower layer tampering).  Label stacking does provide
protection from the layers above, but not from breach within or from
attack from the layers below (including man-in-the-middle attack at
the physical layer).

Curtis

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 10 Aug 2010 07:28:50 +0300

Neil,
Lots of thanks for the clarification.

I fully agree with your point that Ethernet and MPLS-TP are quite different. 
Actually this is the starting point of my disagreement with Maarten.

Specifically about this thread: 
I am not a network security expert - far from it.  However I do not think that OAM architecture per se
would suffice to make OAM secure. IMHO IEEE, when treating security aspects of 802.1ag, has
taken the same position when it recommended to place MPs above the MAC security sub-layer in the
protocol stack. 
Based on this I think that:
- differentiation between MEPs and MIPs that has been an integral part of the Y.1731/802.1ag OAM 
   reference model does not, per se, resolve any OAM security issues in Ethernet networks
- propagation of 802.1ag/Y.1731 to MPLS-TP (as in draft-bhh) does not resolve any OAM security issues
  for MPLS-TP 
- while eliminating these differences may raise additional security issues for MPLS-TP OAM, all such   
   issues should be handled by applying dedicated security mechanisms (e.g., authentication) 
   and not by references to (non-existent) security inherently provided by the reference model of Y.1731.

My 2c,
     Sasha

________________________________________
From: [email-masked] [[email-masked]]
Sent: Monday, August 09, 2010 6:20 PM
To: Alexander Vainshtein; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] MEPs, MIPs and Security (was IPR Disclosure: Alcatel Lucent's Statement about IPR related to draft-ietf-mpls-tp-oam-framework-07)

Sasha,

regards, neil

---

From: <[email-masked]>
Date: Tue, 10 Aug 2010 07:59:11 +0100

Thanks Sasha...a few remarks in-line: 

Sasha wrote 10 August 2010 05:29

> Actually this is the starting point of my disagreement with Maarten.

NH=> Yes, Ethernet and MPLS-TP are indeed very different.  However, I
think Maarten would like to try and unify them by having Ethernet use a
label-swapping approach and try and align on common OAM.  I think this
would not be good idea for many reasons.  Further, when we have
technologies belonging to different network modes there is much more to
peer-interworking that just OAM DP harmonisation considerations.  And of
course, when at least one of the technologies is not TOS (irrespective
of whether they belong to the same network mode or not) then there is no
point to even trying to interwork them anyway....I'll assume it is
obvious why this is.
> I am not a network security expert - far from it.  However I 
> do not think that OAM architecture per se would suffice to 
> make OAM secure.

NH=> I agree.  One has to separate the 2 cases of:
-	malicious security attacks
-	fortuitous security compromises by accidental misconfiguration
or HW/SW defects causing traffic to be misdirected.

We should use OAM to mitigate the risk of the 2nd case here.  It's also
another reason why, for example:
-	the 'always-on' DP OAM needs to be as simple/sparse as possible
because one wants it to be super-reliable...and thus...
-	...we also want to minimise any unnecessary OAM configuration.
This is why I and colleagues here do not like TCM....it is just
something else that can go wrong.

> IMHO IEEE, when treating security aspects of 
> 802.1ag, has taken the same position when it recommended to 
> place MPs above the MAC security sub-layer in the protocol stack. 
> - while eliminating these differences may raise additional 
> security issues for MPLS-TP OAM, all such   
>    and not by references to (non-existent) security 
> inherently provided by the reference model of Y.1731.

NH=> IMO the thing we should be doing in the DP is sending
(unidirectionally) something that looks/feels like a CV message and
contains a proper SA of the connection/LSP.  That is the right OAM
solution.  And if one wants to (rarely) look within the length of the
connection/LSP one should be able to tap-off the CV (or PM) flow at
arbitrary nodes on-demand.  That way one also avoids the unnecessary
config of TCM and thus more things that can go wrong (which one might
argue could also create security issues).

regards, Neil
>      Sasha
<NH snipped to end>