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
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
