Subject: Re: [mpls] MPLS-RT review on draft-farrelll-mpls-opportunistic-encrypt-04.txt

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 17 May 2015 23:00:14 +0100

Hi Mach,

Thanks for your time on this draft.

> BTW, after reading the document, I have the following comments:
> 
> 1.
> Section 1.1
> "...Consideration of the impact of MPLS OS
>    on MPLS Operations, Administration, and Management (OAM) and other
>    MPLS management techniques also needs further exploration."
> 
> OAM is a critical tool for MPLS network, some OAM functions (e.g., LSP Ping,
> traceroute) that depend on special label (Router Alter label, GAL) and TTL may
> not work due to the encryption. Especially the hop-by-hop encrypted scenario.

I actually think you have this the wrong way around.
In hop-by-hop encryption, the packet will be decrypted at each hop so the OAM
packets will be visible and can be processed as normal. However, hop-by-hop
encryption is probably not going to be the normal mode of operation.

More likely to be an issue is how to handle OAM on the LSP that has end-to-end
encryption but where the OAM is targeted at a transit node. That is the issue
that needs further exploration.

> In addition, seems that the following description conflicts with some existing
> definitions.
> For example:
> Section 3, the 3rd para:
> "The MEL MUST have the bottom of stack bit (the S bit) set and MUST be
>    followed by a pseudowire control word [RFC4385].  The format of the
>    control word is described in Section 3.2."
> 
> But RFC5586 says GAL must be at the bottom of the stack. 

I disagree with your interpretation of RFC 5586. I read section 4.2...

   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.

> And for PW, the fat PW also requires to be put at the bottom
> of the stack.

That's an interesting one. We'd need to check it out.
But I think that in both cases we need to understand that in the OE case, the
bottom of the label stack is reached when labels in the clear end and encrypted
labels start. We need to be *very* careful that the encrypted gloop after the
MEL is not treated as a real label. To ensure that we must have the S-bit set in
the MEL. However, once the MEL has been stripped and the packet has been
decrypted, it can continue on its way as a normal MPLS packet if there are more
labels. Thus, in the cases you are worried about, the GAL and the fat PW
indicator *are* at the bottom of the stack, it is just that that bottom is
hidden in the encrypted packet and a false bottom is placed in the packet higher
up the stack before the encryption.

> 2.
> Section 3.1
> "TC:    SHOULD be copied from the TC of the first encrypted label."
> Seems it implies that there MUST be label(s) encrypted, does it and why?
> Are there scenarios that only the MPLS payload encrypted and the label stack
is
> left as cleartext? I personally think there should be. And if so, what the
value of
> TC should it be? There will be no "first encrypted label" then.

Good catch.
Easy fix.

> 3.
> Section 3.1
> "TTL:   SHOULD be set to zero to prevent encrypted packets being
>           accidentally forwarded beyond the point of intended
>           decryption.
> 
> Shouldn't the TTL be set to 1 instead? In my understanding, when received
> packets with TTL=0, the packets will be dropped.

Yes.

> And when do traceroute, the TTL should be set to corresponding value for
> different hops.

I don't think that is relevant. The TTL in the label being used to route the
packet will decrement accordingly. The MEL lies below that label.

> 4.
> Section 4.2.3
> Regarding the Key Exchange Message TLV, where the Path Identifier(24-bit) and
> LSP-ID(32-bit) are designed to carry the LSP-ID, why do they have different
> length?

No reason apart from what fitted in the format.

> Seems that only RSVP-TE based and MPLS-TP LSPs have LSP-ID and the length is
> 16 bit, so what's the LSP-ID for other LSPs ? For example LDP, BGP based, PW
> etc., where LSPs are normally expressed by FECs. IMHO, you may need more
> flexible way to identify and LSP.

Yes. see the note at the bottom of page 22. Suggestions welcome.

> 5.
> 
> Do you consider the MPLS-in-GRE/UDP scenarios? And how does MPLS OS apply
> to those cases?

If the MPLS is in GRE or UDP then there are two options...
1. Encrypt the MPLS before encapsulation. No change to this work is needed.
2. Encrypt the GRE or UDP. Not the business of this document.

Cheers,
Adrian

---

From: Mach Chen <[email-masked]>
Date: Mon, 18 May 2015 03:31:45 +0000

Hi Adrian,

Thanks for your prompt response!

See my reply inline...

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Monday, May 18, 2015 6:00 AM
> To: Mach Chen; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [mpls] MPLS-RT review on
> draft-farrelll-mpls-opportunistic-encrypt-04.txt
> 
> Hi Mach,
> 
> > traceroute) that depend on special label (Router Alter label, GAL) and
> > TTL may not work due to the encryption. Especially the hop-by-hop encrypted
> scenario.
> 

Rethink about this, indeed, hop-by-hop is fine. 

> that needs further exploration.

Yes, traceroute is such a typical scenario. For end-to-end encryption, the transit nodes should not (and for OS purpose, it MUST not) know how to decrypt the packets, then traceroute will fail. 

> 
> > In addition, seems that the following description conflicts with some
> > existing definitions.
> > For example:
> > Section 3, the 3rd para:

At least for MPLS-TP LSP, it is the case, unless the GAL is encrypted.

> 
> > And for PW, the fat PW also requires to be put at the bottom of the
> > stack.
> 
> decrypted, it can continue on its way as a normal MPLS packet if there are
> more labels. Thus, in the cases you are worried about, the GAL and the fat PW
> indicator *are* at the bottom of the stack, it is just that that bottom is hidden
> in the encrypted packet and a false bottom is placed in the packet higher up the
> stack before the encryption.

Yes, as above, then the GAL MUST be encrypted and should not be co-existence in the stack.

> > Shouldn't the TTL be set to 1 instead? In my understanding, when
> > received packets with TTL=0, the packets will be dropped.
> 
> Yes.
> 
> > And when do traceroute, the TTL should be set to corresponding value
> > for different hops.
> 
> I don't think that is relevant. The TTL in the label being used to route the packet
> will decrement accordingly. The MEL lies below that label.
> 
> > 4.
> > Section 4.2.3
> > LSP-ID(32-bit) are designed to carry the LSP-ID, why do they have
> > different length?
> 
> > 16 bit, so what's the LSP-ID for other LSPs ? For example LDP, BGP
> > based, PW etc., where LSPs are normally expressed by FECs. IMHO, you
> > may need more flexible way to identify and LSP.
> 

I also think 4379 like expression is needed.

> 
> > 5.
> >
> > Do you consider the MPLS-in-GRE/UDP scenarios? And how does MPLS OS
> > apply to those cases?
> 

OK, maybe it's useful to add some text to the document to clarify this.

Best regards,
Mach

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 18 May 2015 10:36:09 +0100

> > More likely to be an issue is how to handle OAM on the LSP that has
> > end-to-end encryption but where the OAM is targeted at a transit
> > node. That is the issue that needs further exploration.
> 
> Yes, traceroute is such a typical scenario. For end-to-end encryption, the
transit
> nodes should not (and for OS purpose, it MUST not) know how to decrypt the
> packets, then traceroute will fail.

Yup.
The thing I'd like to look at is whether it would be OK to run the OAM
(specifically intermediate-node action OAM) without encryption. But I think
there are some issues with ECMP.

> I also think 4379 like expression is needed.

Yes, that can probably be the way forward.

> OK, maybe it's useful to add some text to the document to clarify this.

Sure.

Adrian

---

From: Mach Chen <[email-masked]>
Date: Mon, 18 May 2015 09:49:19 +0000

Hi Adrian,

> > nodes should not (and for OS purpose, it MUST not) know how to decrypt
> > the packets, then traceroute will fail.
> 
> Yup.
> (specifically intermediate-node action OAM) without encryption. 

Seems that this is the only feasible way to go. 

>But I think there are some issues with ECMP.

Indeed, you have to introduce EL then.

Best regards,
Mach