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

[Stephen Farrell <[e-mail]>]

On 01/14/2014 12:18 AM, Stephen Kent wrote:
> 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).

I agree that we need to discuss terminology here and would be
fine with OK instead of OE if that's where land. (We mentioned
that terminology may change in the draft for this reason.)

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

There are apparently some kinds of MPLS deployments where nodes are
under the customer's control. But yes, I agree that this potential
mechanism would be of most benefit where >1 administrative entity
is involved and might be of little benefit if that remains very
rare. I am told however that such deployments exist. I think there
may also be cases where MPLS is not carrying IP and where a
(non-collaborative) fibre tap might be a concern.

I think that the meta-point is that we should be chatting with the
MPLS folk to see what they want and are interested in deploying.
Then we can probably figure if some flavour of IPsec will be just
fine or if more (like our draft) is needed.

S.

> 
> Steve
> 
> _______________________________________________
> perpass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/perpass
> 
>