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

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

Hello Lizhong,

Thanks for your time with this draft.

> I have several questions, and would appreciate to resolve them
> before WG adoption.

Thanks for the questions: answers below.
I hope these issues don't really constitute reasons to block adoption as a WG draft.

> Section 2.1, the scale of configuration that is needed for a full set of SAs between
> all communicating parties
> [Lizhong] need to expand acronym "SA", security association?

Yup, need to bring that up from section 2.4.

> Section 3, Everything that follows the control word is the entire original MPLS
> packet encrypted.
> [Lizhong] also for Figure1, in the PHP case, the original MPLS packet will not have
> label, then if the packet is also encrypted and encapsulated after control work, 
> then how to parse the packet correctly? The control word will not tell the following
> payload is MPLS or IP.

Hmmm, you are talking, I suppose, about the hop-by-hop encryption mode on a final hop of an LSP that is using PHP.
In this case there is nothing to encrypt except the payload.
Nevertheless, I am not sure I understand your question. 
Consider what happens when the packet is not encrypted on the final hop of an LSP from LSR Y to LSR Z with PHP in use. In this case LSR Y pops the last remaining label from the packet and forwards it on the designated interface to LSR Z. LSR Z has no control word or other means to use to determine what the received packet is. It may sniff the first nibble if it knows the packet is IPv4 or IPv6, or if it hopes to find a PW control word. Or LSR Z may know something magic about the incoming interface (for example that it is an MPLS interface and that the packet will have more labels).
Now if encryption is in use, then LSR Z has agreed to its use. That means that LSR Z is expecting to label 15, the MEL, and a control word at the top of the packet. So it will remove those three things, decrypt the packet, and then treat the rest of the packet exactly as it would in the case where encryption is not in use.

We could clarify this by noting that the label stack shown on the left hand side of Figure 1 is of arbitrary depth. That would include zero labels in the PHP case. However, I think this is a bit obvious.

> Section 3, The payload is the data carried by the MPLS packet (such as IP) and
> may be prefixed by a control word.
> [Lizhong] if the control word is optional, then do we need any negotiation
> mechanism to enable control word or not?

Nope. This is describing the pre-encryption payload. I.e., the payload of a regular MPLS packet. The presence or absence of a control word is irrelevant since it is treated as part of the payload.

> When decryption at the egress LER, the TTL&TC processing of the first decrypted
> label should be a bit different with previous mechanism. The TTL&TC value may
> need to inherit from the label before MEL in uniform mode.

Indeed. This is how tunnelling works. You think we should explain that?

Cheers,
Adrian

---

From: Lizhong Jin <[email-masked]>
Date: Mon, 18 May 2015 11:15:08 +0800

Hi Adrian,
Thanks for the prompt reply. See inline below.

Regards
Lizhong

> I hope these issues don't really constitute reasons to block adoption as a
[Lizhong] not blocking issue, only need clarifications.

> Consider what happens when the packet is not encrypted on the final hop of
> an LSP from LSR Y to LSR Z with PHP in use. In this case LSR Y pops the
> last remaining label from the packet and forwards it on the designated
> interface to LSR Z. LSR Z has no control word or other means to use to
> determine what the received packet is. It may sniff the first nibble if it
> knows the packet is IPv4 or IPv6, or if it hopes to find a PW control word.
> Or LSR Z may know something magic about the incoming interface (for example
> that it is an MPLS interface and that the packet will have more labels).
> Now if encryption is in use, then LSR Z has agreed to its use. That means
> that LSR Z is expecting to label 15, the MEL, and a control word at the top
> of the packet. So it will remove those three things, decrypt the packet,
> and then treat the rest of the packet exactly as it would in the case where
> encryption is not in use.
>
> We could clarify this by noting that the label stack shown on the left
> hand side of Figure 1 is of arbitrary depth. That would include zero labels
> in the PHP case. However, I think this is a bit obvious.
>
[Lizhong] Let my try to describe with an example. In Ethernet environment,
LSR Z receives the packet, and parse the payload by checking EthType, with
"0x80" as IPv4. When MEL is inserted, the EthType has to be changed to
"MPLS" type (0x8847/8848), and lost the original payload type information.
And the MEL and control word does not have capability to indicate the
payload type for parsing.

> Nope. This is describing the pre-encryption payload. I.e., the payload of
> a regular MPLS packet. The presence or absence of a control word is
> irrelevant since it is treated as part of the payload.
>
[Lizhong] got it, I miss reading it.

> Indeed. This is how tunnelling works. You think we should explain that?
[Lizhong] Yes, it is better to mention that, or have a reference in the
draft.

---

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

Hi again,

>>>> Section 3, Everything that follows the control word is the entire 
>>>> original MPLS packet encrypted.
>>>
>>> [Lizhong] also for Figure1, in the PHP case, the original MPLS packet will 
>>> not have label, then if the packet is also encrypted and encapsulated 
>>> after control work, then how to parse the packet correctly? The control
>>> word will not tell the following payload is MPLS or IP.
>>
>> Hmmm, you are talking, I suppose, about the hop-by-hop encryption mode
>> on a final hop of an LSP that is using PHP.
>> Consider what happens when the packet is not encrypted on the final hop
>> of an LSP from LSR Y to LSR Z with PHP in use. In this case LSR Y pops the last
>> remaining label from the packet and forwards it on the designated interface
>> to LSR Z. LSR Z has no control word or other means to use to determine
>> what the received packet is. It may sniff the first nibble if it knows the
>> packet is IPv4 or IPv6, or if it hopes to find a PW control word. Or LSR Z may
>> know something magic about the incoming interface (for example that it is
>> an MPLS interface and that the packet will have more labels).
>> of the packet. So it will remove those three things, decrypt the packet, and
>> then treat the rest of the packet exactly as it would in the case where
>> We could clarify this by noting that the label stack shown on the left hand
>> side of Figure 1 is of arbitrary depth. That would include zero labels in the
>> PHP case. However, I think this is a bit obvious.
>

You're right. With PHP in my example, LSR Y (that strips the label) determines what the packet type is, and uses that to set the Ethertype. Using encryption, it would be LSR Z that had to do this. But it would be the same function.

An alternative here would be to run encryption only as far as the penultimate hop, but that leaves the last hop exposed.

So, to me it seems that if you want to run end-to-end encryption, you probably want to run it without PHP.

>>> When decryption at the egress LER, the TTL&TC processing of the first
>>> decrypted label should be a bit different with previous mechanism. 
>>> The TTL&TC value may need to inherit from the label before MEL in
>>> uniform mode.
>>
> [Lizhong] Yes, it is better to mention that, or have a reference in the draft.

OK. Will do.

Cheers,
Adrian

---

From: Lizhong Jin <[email-masked]>
Date: Mon, 18 May 2015 18:04:04 +0800

Hi Adrian,
We are aligned now. If I compare the MEL+ControlWord with ESP/AH in IPSec,
there is "Next Header" in ESP/AH to indicate the encrypted payload type.
For current mechanism, the MEL should not be inserted/applied in PHP case.

Lizhong

On Mon, May 18, 2015 at 4:57 PM, Adrian Farrel <[email-masked]> wrote:

> hand
> You're right. With PHP in my example, LSR Y (that strips the label)
> determines what the packet type is, and uses that to set the Ethertype.
> Using encryption, it would be LSR Z that had to do this. But it would be
> the same function.
>
> An alternative here would be to run encryption only as far as the
> penultimate hop, but that leaves the last hop exposed.
>