1

I've read this blog post, which said that "Unlike some other protocols, the source for GRE packets cannot be faked or spoofed." But why?

What is preventing me from setting an arbitrary source IP in any of the IP headers? If I have the following setup:

------------- 1.2.3.4               5.6.7.8 -------------
| Network A |———————————————————————————————| Network B |
| 10.1/16   |                               | 10.2/16   |
-------------                               -------------

If I understood correctly, an attacker could send a crafted GRE packet with:
Outer IP: Src 1.2.3.4, Dst 5.6.7.8
Inner IP: Src 10.1.0.2, Dst 10.2.5.5

The border router of Network B should have no way of detecting that this packet is malicious and doesn't originate from Network A and will happily forward it into its network.

Did I miss something?

Further question: If I want to authenticate my peer, I could use IPSec without encryption instead of GRE, right?

Improve this question

2 Answers 2

Reset to default
2

The original RFC 1701 GRE allows for a sequence number, and attacker in the situation you describe would need to know what that is. TCP has something similar with a sequence number.

The following RFC 2784 GRE eliminated the sequence number, but it was updated by RFC 2890, Key and Sequence Number Extensions to GRE that specifies a key and sequence number for GRE that would be necessary in the situation you describe for an attacker to know.

Improve this answer
7
  • According to RFC2890, packets whose seq no are greater than the current seq no, are placed in a buffer. After a defined time, these packets are decapsulated. And both, key and seq no, could be snooped and provide no real authentication.
    – Gabscap
    Commented Feb 15, 2023 at 23:25
  • Your scenario does not include snooping, which is a completely different question. That is something completely different. Simply guessing a the key and valid sequence number is a remote possibility.
    – Ron Maupin ♦
    Commented Feb 15, 2023 at 23:42
  • Then lets forget snooping. But the key and seq no fields are not used by default (for linux + iproute2). So many installations could suffer from the scenario described above?
    – Gabscap
    Commented Feb 15, 2023 at 23:46
  • 1
    Ok, Cisco also doesn't include the key and seq no by default. But thats not even the core of my question anyway. GRE packets without the key and seq no fields are still valid GRE packets, since they are optional. I was wondering why a cloudflare post claims, that GRE packets could not be spoofed.
    – Gabscap
    Commented Feb 16, 2023 at 0:11
  • 1
    @Gabscap, if your primary aim is to find out why they claimed that, you should ask them directly. They might update the blog to clarify the claim. Perhaps they simply meant that GRE source can't be spoofed as a means to effectively create a DDoS. Not that it can't be spoofed at all.
    – FrameHowitzer
    Commented Feb 16, 2023 at 14:55
2

Cloudflare is mistaken. You can indeed spoof (lie about) the origin of GRE traffic, and DDoS attackers DO. Thus you would not know where the traffic actually came from. BUT, if the additional features of sequence numbers and keys are used, it's unlikely an attacker would be able to send valid spoofed traffic. DDoS attackers don't care; they're just out to flood the interface and/or application.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.