Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt

[Stephen Kent <[e-mail]>]

Folks,
>> On Fri, 10 Jan 2014, Stephen Farrell wrote:
>>
>>>> - I understand MPLS traffic is often protected at a higher layer by
>>>> IPsec. If we had a good opportunistic solution for IKE/IPsec, it could
>>>> also cover this use case. And we know people are working on such
>>>> solutions. [Here, that's me and my little turf war].
>>>
>>> I think opportunistic IPsec could certainly help yes. I'm not
>>> sure if this use-case is being considered in that work.
>>
>> Any non host-host case is very hard, as there is no way to verify any
>> claims for random subnets of the internet. AFAIK, no good methods exist
>> that any OE IPsec could use for auto-configuration. There is quite a
>> difference between "here is plaintext from you to Bob, encrypt it" and
>> "here is plaintext from you to Bob at 8.8.8.0/24, encrypt to Mallory".
>>
> This is different from the normal IPsec OE scenario, and as a result 
> may be easier to solve:
because it is different, I suggest that we not call it OE, which is 
clearly defined in RFC 4322.
I suggest opportunistic keying (OK).
> - The MPLS peer is already willing to send any traffic from the 
> private network to the other peer, which it sincerely hopes is not a 
> MITM.
> - Each peer is typically running on an edge router (I believe) and so 
> has much more awareness of the network than your typical IPsec OE 
> peer. They will actually have the BGP information.
I believe that the MPLS peers, as edge routers, are not under the 
control of the end users,
as would more likely be the case for IPsec gateways operating at about 
the same point in
the path. So, an important part of this discussion is that the 
administrative entities managing
the encryption are ISPs, not subscribers. Thus the confidentiality 
afforded here is more of
an ISP service than a subscriber-controlled service. Also, unless the 
MPLS path crosses AS
boundaries (not yet common, I believe) this offers less protection than 
IPsec could.

Steve