Re: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt

[Curtis Villamizar <[e-mail]>]

Sasha,

Thanks for trimming.  I further trimmed and also dropped mpls-tp.

This email has suggested change to the internet-draft below.

It is important that any proposal to use GAL with PW not break
traceroute on the containing LSP.  Since a goal is to also suport
MS-PW (as you point out below) and LSP hierarchy, an LSR needs to be
able to forward payload containing GAL.  See inline to keep the
context.

Btw - the new name of the document is:
draft-ietf-pwe3-mpls-tp-gal-in-pw-00.txt

Another suggestion is why not drop the -TP from the title.  GAL
applies to all MPLS, not just -TP.

Curtis


In message <[e-mail]>
Alexander Vainshtein writes:
>  
> Curtis, 
> Please see inline below. I've snipped the text that is not relevant
> to my comment.
>  
> Regards,
>      Sasha
>  
> ________________________________________
> From: [e-mail] [[e-mail]]
> Sent: Saturday, March 26, 2011 4:02 AM
> To: Alexander Vainshtein
> Cc: Greg Mirsky; [e-mail]; Robert Rennison; [e-mail]; [e-mail]; [e-mail]; pwe3; HUANG Feng F
> Subject: Re: [mpls-tp] [PWE3] [mpls] WG LC draft-lm-pwe3-mpls-tp-gal-in-pw-00.txt
>  
> In message <[e-mail]>
> Alexander Vainshtein writes:
> >
> ... snipped ...
> >> And, last but not least, if we decide to allow GAL in the middle
> >> of the label stack  
> >> (overriding RFC 5586 and RFC 5960), we must also define how a
> >> pack et with GAL  
> >> in the middle of the label stack is forwarded when GAL is exposed, 
> >> similar to what has been done in RFC 3032 for RAL.
> >>
> >> My 2c,
> >>      Sasha
>  
> > If GAL is encountered, then it is processed just as it would be if TTL
> > was set high and GAL was encountered as a result of the final POP in a
> > containing LSP exposing only the GAL.  The G-Ach is after the bottom
> > of stack, where ever bottom of stack is found.
>  
> > Curtis
>  
> IMHO this would not work for, say MS-PWs with GAL above the PW label
> as proposed in draft-nadeu. 


A few simple rules would work for LSP ping (not using TTL), LSP
traceroute (using TTL), PW ping (including MS-PW, not using TTL), and
MS-PW traceroute (using TTL to identify the set of S-PE).

  original (rfc5586.txt):

   In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs,
   Concatenated Segments of LSPs, and with Sections, and MUST NOT be
   used with PWs.  It MUST always be at the bottom of the label stack
   (i.e., S bit set to 1).  However, in other MPLS environments, this
   document places no restrictions on where the GAL may appear within
   the label stack or its use with PWs.  Where the GAL is at the bottom
   of the label stack (i.e., S bit set to 1), then it MUST always be
   followed by an ACH.

   The GAL MUST NOT appear in the label stack when transporting normal
   user-plane packets.  Furthermore, when present, the GAL MUST NOT
   appear more than once in the label stack.

  replacement:

   In MPLS and MPLS-TP, the GAL MUST be used with packets on a G-ACh
   on LSPs, Concatenated Segments of LSPs, and with Sections.  GAL MAY
   be used with PWs.  It MUST always be at the bottom of the label
   stack (i.e., S bit set to 1).  GAL must appear immediately below
   the label for which a G-Ach is associated.  The ingress SHOULD
   determine whether labels below GAL are supported by intermediate
   and egress LSR, otherwise GAL must also be at the bottom of the
   stack.  

   The GAL MUST NOT be added to normal user-plane packets.  User-plane
   packets which already contain GAL may be transported.  When
   present, the GAL MUST NOT appear more than once in the label stack.

At some later point in the document (could be section 3 and 4) add:

  Backwards compatibility:

   In order to insure that LSR which strictly conform to [RFC5586] and
   require that GAL be on the bottom of the stack, an ingress SHOULD
   determine whether all intermediate LSR and the egress LSR support
   labels after the GAL label.

   <<< add mechanism to advertise capability here or disclaimer that
       it is elsewere in some ISIS or OSPF extensions >>>

  Rules for handling GAL and TTL expired with GAL:

   GAL MUST be place directly beneath label for the LSP or PW for
   which the channel is relevant.  Additional labels MAY be placed
   below GAL to affect packet entropy based decisions at multipoint
   links such as link bundles and Ethernet LAG.  See [Backwards
   compatibility] for limitations on labels below GAL.

   LSR using label stack based packet entropy based decisions at
   multipoint links SHOULD ignore a GAL label for the purpose of
   entropy harvesting and continue entropy harvesting as though GAL
   were not present.

   When processing TTL Expiration on a packet, if the label
   immediately following is GAL, then a ACH MUST be immediately below
   the bottom of the MSPL stack and the ACH must be processed.

   When a LSP POP or PW POP occurs, if the next label is GAL, then a
   ACH MUST be immediately below the bottom of the MSPL stack and the
   ACH must be processed.

Note that for PW, GAL is after the PW label and before the fat-pw
label (if present).

We also need to change the security section a bit.

   Refer to [RFC5586] for general MPLS security considerations.

   GAL in user payload must be forwarded to support GAL at a client
   layer.  If an LSR interprets GAL at the bottom of stack to be
   relevant to a G-Ach for the label for which a TTL has expired, then
   a client layer G-Ach payload may be applied to a server layer.
   Use of the uniform model, or a pipe model TTL set too low with an
   attack which increases hop count (physical attack), plus an LSR
   that erroneously interprets GAL anywhere in the stack or at bottom
   of stack to be a G-Ach at the layer for which TTL has expired,
   provides a low probability attack vector.

   This attack vector would only exist if intermediate LSR on the path
   interpretted TTL anywhere in the stack or at bottom of stack as
   their own G-Ach.  This document requires that the GAL only be
   considered if it is immediately following a TTL expire or POP.
   [RFC5586] is silent on forwarding (or not forwarding packets
   contraining GAL at the ingress to a hierarchical LSP, and is
   unclear as to whether TTL expired can be applied to GAL at the
   bottom of stack well below the label for which TTL expired.

   The vulnerability is associated with the behaviour defined in
   [RFC5586] and would be fixed if all LSR conformed to the updates to
   [RFC5586] in this document.

   The potential for this attack vector to become exploitable as a
   result of an older LSR which adheres only to [RFC5586] can be
   eliminated by offering an option to block forwarding of traffic
   containing GAL if the backward compatibility check defined in
   [Backwards compatibility] reveals intermediate or egres LSR not
   advertising the capability defined in this document.  LSR SHOULD
   provide such an option.