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

[Gert Doering <[e-mail]>]

Hi,

On Sun, Oct 24, 2021 at 08:55:17PM +0000, Eric Vyncke (evyncke) wrote:
> But, I fail to understand whether the issue is limited to SRH or
> is actually applicable to any tunnel ? As you described, in any
> encapsulation mechanism, BCP38 will be applied on the outer header
> in the ???underlay??? and the encapsulated packet will indeed
> traverse any network until the endpoint [1]. Therefore, to handle
> the case when one endpoint of the tunnel is compromised, the other
> endpoint should apply BCP38 on the decapsulated traffic based on
> the other side of the tunnel.

It is applicable to any tunnel that will decapsulate packets from
arbitrary (outside) sources.

So, for example, a normal GRE tunnel would only accept packets from (outer) 
sources matching the configured "tunnel destination" peer address, and
you could configure BCP38 for the "inside" addresses (given that GRE
tunnels are usually presented as virtual interface with routes pointing
to it, and ACLs/BCP38 being applicable).

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


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

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

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