Stephen,
I think opportunistic IPsec could certainly help yes. I'm not sure if
this use-case is being considered in that work.
I think it out to be. Experience has shown that getting all of the
details right for a
layer 3 security protocol is hard. BTW, MPLS is (lower) layer 3, not
layer 2.
- But even at layer 2, there are existing solutions like WPA or MacSec.
Can none of them be used (or extended) for this use case and do we
really have to develop both the bulk encryption and key exchange from
scratch?
And that too.
However, my understanding of MPLS is that basically neither IPsec
nor layer 2 crypto are used in many or possibly most cases. My hope,
(and I'd not put it stronger than that for now), is that this might
be a another useful tool in the tool-box that could have a better
chance of being deployed if we develop it with together with MPLS
folks who'd like such a tool. Though I'm sure there'll be MPLS
and other folks who hate the idea as well, we'll see.
I suspect you're right that IPsec is not used often in this context.
The use of MPLS would be qualitatively different, because it would
be offered by an ISP, not by a subscriber. Maybe that would result
in more encrypted traffic because ISPs would offer it as a low
cost service.
Overall, my goal is to get some crypto that's deployable for
protecting MPLS traffic and I'm not fussed whether that means
re-using a flavour of IPsec nor some L2 stuff from elsewhere, nor
whether it turns out that we need to re-do some things in a way that
works better for our "customers" as in the proposal here.
L2 stuff won't work across AS boundaries, unless the MPLS
tunnel crosses those boundaries.
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
