RE: [mpls] Proposed reforming of LSP Ping TLV processing

[<[e-mail]>]

Adrian/guys,

Just an observation of what the real architectural problem is here
(though I hasten to add we can do nothing about this now...too late):

When one designs a layer network (any mode/technology) one MUST ensure
that the characteristic information (CI - which is a term from func arch
that has a very specific meaning, but I can't really get into detail of
what this means here) that is created/removed at trail/flow termination
points is ALWAYS consistent (and a key corollary of this is that the CI
MUST be client independent).  One rather important observation here is
that the OAM of a layer network is injected/extracted at trail/flow
termination points and thus forms an intrinsic part of the CI of a layer
network.

MPLS does not have consistent CI for a whole raft of reasons, eg the
label field can take on different semantics depending on what
protocol/use-case generated it....I can list at least 4 different
semantics here.

What this means practically is that under misconnectivity defects the
true intended meaning of a functional field in a traffic unit can be
misunderstood by whichever node terminates the offending misconnected
traffic units.....which also includes the OAM pkts.  So yes, Tom is
right to point out that there are potential security implications
here.....but just be aware that this is a symptom/consequence of not
having consistent CI in the 1st place, and its a bigger problem than
just the one being discussed.

Don't want start a debate on this as there is nothing much we can do
about it...because as I already noted it's too late.....but I did want
to point out what the underlying architectural issue is here.

regards, Neil

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[e-mail]] 
> Sent: 23 July 2007 19:38
> To: Adrian Farrel
> Cc: [e-mail]
> Subject: Re: [mpls] Proposed reforming of LSP Ping TLV processing
> 
> 
> 
> 	It looks like your Security Considerations section is
> a little light. *)
> 
> 	--Tom
> 
> > Hi,
> >
> > I should have introduced this sooner...
> >
> > George and I have thrown together a draft that we have been talking
> > about for some time. "Future-Proof TLV Codepoint Space for LSP  
> > Ping" (http://www.ietf.org/internet-drafts/draft-farrel-mpls-lsp- 
> > ping-tlvs-00.txt) is intended to allow LSP Ping extensions to be  
> > backward compatible by defining processing rules for TLVs based on  
> > the ranges from which the Type value is allocated. Or, phrased a  
> > different way, to set aside two bits from the TLV Type to define  
> > the processing rules.
> >
> > This first version of the draft is pretty rough, but we hope that
> > the ideas will carry forward and gain working group consensus. If  
> > so, the main impact would be to update the IANA registry. New LSP  
> > Ping TLVs (and sub-TLVs) would then have to indicate the 
> processing  
> > rules when the TLV is not understood.
> >
> > If you have any questions then please send mail, or corner me or
> > George during the week.
> >
> > Thanks,
> > Adrian
> >
> >
> >
> > _______________________________________________
> > mpls mailing list
> > [e-mail] https://www1.ietf.org/mailman/listinfo/mpls
> 
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mpls
> 


_______________________________________________
mpls mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpls