If your MPLS L3VPN supports IP transport from endpoint A to/from endpoint B at the other site (which is their primary purpose), there's nothing to stop you from letting A and B talk IPSec (in one or another variety) to each other.
That would be IPSEC-over-MPLS-L3VPN, and to the underlying MPLS network (or the L3VPN service it offers), this would be just like any other IP traffic from A to B, it would just happen to look like IP protocol 50 or udp/4500, with some udp/500, occasionally.
Actually, GETVPN is something quite like that: A carrier/service provider offers a service interconnecting many sites with "native" spoke-to-spoke capablity, and the (usually) enterprisey customer attach their endpoints (their GETVPN speaking routers) to it. The GETVPN routers orchestrate their GETVPN over the provider's service, using their variant of IPSec. Done.
But I think you were rather looking in the direction of what usually is/was answered by running MPLS-over-GRE-over-IP(Sec), to extend label switching connectivity across a (secured) tunnel over an (untrusted) network.
Yes, that can be done, but there's quite a few caveats.
Just some that spring to mind:
- SLA: MPLS based VPN services used to be built and bought with SLAs and QoS in mind. There's no SLA on the open Internet. Reconvergence times (minutes) are not comparable to an SP's backbone (seconds).
- QoS: You can copy the inner header's DSCP bits to the outermost IPSec header as much as you like - once the packets the leave your network, no one can tell what's inside, and the DSCP bits in the outermost header are going to be disregarded (in any case) or nullified (probably) by the ISPs.
- Hardening/Security Policy: Exposing an MPLS speaking node (P or PE) to the open Internet is going to lead to debates, and would certainly demand rigid hardening. Depending on the given security policy, the MPLS speakers might have to resort to running MPLS-over-GRE, while a dedicated security device (attached to the Internet) would do the IPSec part.
- MTU and fragmentation: While an enterprise's or carrier's MPLS backbone usually just doesn't care because it is jumbo frame enabled, be prepared to be bitten by the old PathMTU snake when running MPLS-o-GRE-o-IP(Sec). Label stack, GRE header, outer IPSec header, PPPoE headers are all going to eat into your end to end PathMTU to begin with. And just when you think you figured it all out, there's a device in the path that ignores the DF-bits and fragments the packets anyway (sometimes unnoticeably, sometimes at a detrimental performance impact), or a combination of PPPoE and NAT-T crops up, and another 8 bytes are gone.