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

["Adrian Farrel" <[e-mail]>]

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.
>> 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.
>
> [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. 

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.
>>
>> 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.

OK. Will do.

Cheers,
Adrian