From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Lizhong Jin'" <lizho.jin@gmail.com>
References: <031c01d090f2$b71ab2d0$25501870$@olddog.co.uk>
 <CAH==cJy6VPJ8MjtwOVBx8EcJQSq3ECOWSiGfke-gK1akb-tyrg@mail.gmail.com>
In-Reply-To: <CAH==cJy6VPJ8MjtwOVBx8EcJQSq3ECOWSiGfke-gK1akb-tyrg@mail.gmail.com>
Date: Mon, 18 May 2015 09:57:10 +0100
Message-ID: <038a01d09148$a2f87890$e8e969b0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQLtMjKmdsdmJhBs/CHK4l2DStnr9gJhehHrmzUS0oA=
Content-Language: en-gb
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/hImoaHKED6qEVJhQLR2nXUhxaHY>
Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org, mpls@ietf.org,
 mpls-chairs@tools.ietf.org
Subject: Re: [mpls] MPLS-RT review of
 draft-farrelll-mpls-opportunistic-encrypt-04.txt
Precedence: list
Reply-To: adrian@olddog.co.uk

Hi again,

>>>> Section 3, Everything that follows the control word is the entire=20
>>>> original MPLS packet encrypted.
>>>
>>> [Lizhong] also for Figure1, in the PHP case, the original MPLS =
packet will=20
>>> not have label, then if the packet is also encrypted and =
encapsulated=20
>>> 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.=20

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.=20
>>> 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