Subject: [PWE3] Re: progress of G.8113 and G.8114

From: "Thomas Walsh" <[email-masked]>
Date: Wed, 9 Jan 2008 16:23:11 -0500

Before ITU-T determines there are unresolvable issues that require a new
protocol, those advocating a new protocol have the obligation to bring
the issues to IETF - not the other way around.  

Since G.8114 is not approved by ITU-T the BFD issue remains open - not
closed as Martin declares.

Tom

Martin Vissers wrote:
 
<Monique,
 
As you have suggested, let's stay with technical OAM issues.
Your question is not a technical OAM question, it's abon a
transparent manner.

If the hacker could bypass the UNI and have access to e.g. the access
line, the transport network will provide encryption on this access line;
e.g. MAC-Sec should be deployed in those cases. If hackers could have
access to the NNIs between the operator's offices, then the operator
will also provide encryption on these NNIs.

Clause 13 of G.8110.1 describes some other cases and how T-MPLS networks
(like any other transport network, including SDH, ATM, OTN, Ethernet)
deal with it.

I hope this indicates that "spoofing of such messages is" NOT "trivial"
and that "the impact on the OAM function is" NON EXISTING. I.e. the
opposite of your assumptions/gut feeling.

Note that T-MPLS deploys the same security measures as Ethernet and that
T-MPLS OAM is a copy of Ethernet OAM.

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: woensdag 9 januari 2008 16:01
To: VISSERS Maarten
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant; David Ward
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

Maarten and all,
I have looked up the PDF table you've attached to your message, and at
least one row - Security - looks highly suspicious to me.

This row states (unless I've missed something) that the security
function for ETH OAM a is based on the ME Level check, and that for
T-MPLS - on label stacking.  AFAIK, both ME levels and stacked labels
are transmitted in cleartext. 
I am neither a security expert nor a professional hacker, but it seems
to me that snooping upon and spoofing of such messages is pretty trivial
while the impact on the OAM function is potentially disastrous (consider
a malicious user spoofing CCM frames/ CV packets with the RDI flag set).
The BFD authentication procedures that use field-proven digital
signature techniques look much more robust to me.

To me as an individual (my company is not an ITU-T member), this
observation, combined with your statement from another email on this
thread:

<quote>
	As far as the participants understood the BFD specification, use
of BFD
	within T-MPLS instead of use of CV would have introduced a
security risk
	in T-MPLS networks. 
<end quote>

raises the question of overall soundness of the technical analysis that
has resulted in the decision to reject usage of BFD in T-MPLS: If
something so easy to catch has passed unnoticed, what else has been
possibly mis-judged? 

The gut feeling (triggered by David's emails on the same thread) that
the IETF BFD experts (either as a body or as individuals) have not been
consulted makes this question even more relevant.

Regardless of the formal procedures, IMHO the "right and proper" thing
to do would be to present your analysis (with sufficient technical
details) to the relevant IETF WGs, (BFD, MPLS and PWE3) and to ask for
their feedback. It would be definitely better to do so before taking the
decision, but late is better than never. 

My 2c.
                    Sasha Vainshtein

-----Original Message-----
From: VISSERS Maarten [mailto:[email-masked]]
Sent: Tuesday, January 08, 2008 9:34 PM
To: David Ward
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

 David,

Sometimes I have the feeling that MPLS OAM addresses yesterdays
requirements and T-MPLS (and Ethernet) OAM addresses tomorrows
requirements... as well known, it is possible to go from yesterday to
tomorrow, but it is not possible to go from tomorrow to yesterday...

To address the interoperability between TMPLS and MPLS/PWE, we can learn
from the interoperability between ATM and FR, ATM and MPLS. TMPLS has a
much richer OAM set then MPLS/PWE and as long as this is the case,
interoperability will require an interworking function that is able to
translate the common OAM functions and terminate all other OAM
functions. Once MPLS/PWE OAM has been extended and supports "tomorrows
OAM set", this interworking function can become trivial, and become like
the Ethernet to T-MPLut who should
have done what and when and how many interpretations can we give to
words in a report. As I have indicated, your company should have raised
the issue in the IETF. Your company did not do this. So for this version
of G.8114 this issue is closed.
 
I look forward to a technical OAM contribution from you.
 
Regards,
Maarten >
_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Thomas Walsh" <[email-masked]>
Date: Wed, 9 Jan 2008 16:23:11 -0500

Tom

Martin Vissers wrote:
 
<Monique,
 
Your question is not a technical OAM question, it's about who should

Regards,
Maarten >