Re: [v6ops] Security issues in RFC8754 and related/subsequent drafts?

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Gert,

Long time not see... I hope that all is well for you and your relatives

<still wearing not specific hat>

See below for EV> and I have elided some texts when we agree.

Regards

-éric

On 25/10/2021, 08:22, "Gert Doering" <[e-mail]> wrote:

...%<....%<.....

    [..]
    > About the looping attacks, there is no amplification here as the
    > compromised host needs to generate N packets to force the non-compromised
    > tunnel endpoint to generate N (shorter) packets. The RFC 6324
    > describes a related attack by with amplification using ISATAP.

    The looping attack is similar to what was described for RH0 - you send
    one packet, but that packet traverses the target network multiple times,
    pingponging between participating routers.

EV> Of course RH-3 (RFC 6554) and RH-4 (RFC 8754) have the same issues as RH-0 and we all know that the RH-0 issue was documented a long time ago by RFC 5095. RPL & SRH are per design limited in a specific domain (and SRH can even have a HMAC TLV -- even if not protecting against a compromise SRH node)

EV> My reading of Andrew's original email is that the attack is different than the good old RH-0 attack: a compromised router A sends an encapsulated packet to B, which decapsulates and sends the decapsulated packet back to A, which is then re-encapsulated an so on... This is different than the RFC 5095 attack: an in-domain node must be compromised and there is only a x2 amplification by B sending the traffic to A. Of course, A could send its SRH with a convoluted route to 'burn' more bandwidth. But, honestly, if I 'pawned' a router, then I would rather attack the control plane than the data plane.

    > It is clear that tunnel endpoints (whether GRE, ISATAP, IPsec,
    > or even SRH) should not trust blindly any packets and should only
    > decapsulate valid packets (based at the minimum on source address
    > and applying BCP38 and infrastructure ACL at their edge ??? if
    > applicable). In the case of SRH[2] (or any RH actually even MIPv6
    > or RPL), this function should not be enabled by default and must
    > be configured correctly.

    So, if you turn on SR6 in your network, how would you protect said 
    network against malicious hosts *in* your network?

EV> it is clear that hosting VMs in your SRv6 'underlay' is probably not really wise ;-) 
EV> AFAIK, the SRv6 use cases are L[23]VPN or Data Center fabric. And in the case of MPLS-VPN, having a compromised P or PE router can also have devastating consequences. I.e., nothing really new under the Sun

    Of course "not using SR6" or "block all EH from hosts" is a viable 
    strategy, but might not be how the inventors intended things to be used...

EV> if a transit provider on the public Internet enables blindly RPL or SRH on her/his network, then this won't be really smart as well. The same applies for a vendor shipping routers/VM with RPL/SRH enabled by default.

EV> forwarding RH-3 or RH-4 on your network as long as the DA does not trigger any RH processing is perfectly fine of course (it takes 10 minutes to craft a SHR/RPL packet with scappy and send it anywhere and it will arrive at destination most probably)


    Gert Doering
            -- NetMaster
    -- 
    have you enabled IPv6 on something today...?

    SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
    Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
    D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
    Tel: [phone]         USt-IdNr.: DE813185279