Subject: [Int-area] Kathleen Moriarty's Discuss on draft-ietf-intarea-gre-mtu-04: (with DISCUSS)

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 13 May 2015 19:14:05 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-intarea-gre-mtu-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-intarea-gre-mtu/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for your work on this draft, I have a question I'd like to discuss
to see if another security consideration needs to be added.  This should
be very quick to resolve.

Do we need to worry about fragmentation overlap attacks when packets are
reassembled?  I see that you would not have to worry about it in cases
where fragmentation is handled at a different layer as is the case with
some of the methods as it might be addressed at that layer.  Or does it
not matter as the reassembled packets would be forwarded and the device
reassembling wouldn't be processing the payload where an exploit could
avoid detection?

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 14 May 2015 03:39:05 +0000

Kathleen,

AFAIK, most IP stacks include code that detects fragmentation overlap attacks. (Do I have that right?)

So, reassembly attacks shouldn't be effective whether reassembly is performed at the GRE egress or the ultimate destination.

If reassembly is performed at the ultimate destination, the two endpoints might be alerted. However, if reassembly is performed at the GRE ingress, the endpoints might never be alerted.

Should we add a paragraph about this in Section 5 (Security Considerations). Or is this just another type of DoS attack, which we have already mentioned?

                                                                                                        Ron

> -----Original Message-----
> From: Kathleen Moriarty [mailto:[email-masked]]
> Sent: Wednesday, May 13, 2015 10:14 PM
> To: The IESG
> Cc: [email-masked]; draft-ietf-intarea-gre-
> [email-masked]; [email-masked]; draft-ietf-intarea-gre-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Kathleen Moriarty's Discuss on draft-ietf-intarea-gre-mtu-04: (with
> DISCUSS)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Thanks for your work on this draft, I have a question I'd like to discuss to see
> if another security consideration needs to be added.  This should be very
> quick to resolve.
> 
> where fragmentation is handled at a different layer as is the case with some
> of the methods as it might be addressed at that layer.  Or does it not matter
> as the reassembled packets would be forwarded and the device

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 14 May 2015 03:59:38 +0000

Hi Ron,

> Should we add a paragraph about this in Section 5 (Security Considerations). Or is this just another type of DoS attack, which we have already mentioned?

I think it might merit a separate mention since the draft is concerned 
with fragmentation. You can use RFC1858 as a reference for IPv4 and 
RFC5722 as a reference for IPv6 for handling of the overlapping fragment 
problem.

Thanks
Suresh

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 14 May 2015 08:32:33 -0400

On Wed, May 13, 2015 at 11:59 PM, Suresh Krishnan <
[email-masked]> wrote:

> > So, reassembly attacks shouldn't be effective whether reassembly is
> performed at the GRE egress or the ultimate destination.
> >
> > If reassembly is performed at the ultimate destination, the two
> endpoints might be alerted. However, if reassembly is performed at the GRE
> ingress, the endpoints might never be alerted.
> >
> > Should we add a paragraph about this in Section 5 (Security
> Considerations). Or is this just another type of DoS attack, which we have
> already mentioned?
>

A separate paragraph would be helpful, thanks.  This attack type could lead
to a compromise, so the concern (for me at least) is much higher than a
DoS.  I'm glad it's addressed in code and it would just be good to mention
considerations.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 14 May 2015 14:15:03 +0000

Hi Kathleen,

I will have text later today.

                                      Ron

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Thursday, May 14, 2015 8:33 AM
To: Suresh Krishnan
Cc: Ronald Bonica; The IESG; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-intarea-gre-mtu-04: (with DISCUSS)

On Wed, May 13, 2015 at 11:59 PM, Suresh Krishnan <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ron,

A separate paragraph would be helpful, thanks.  This attack type could lead to a compromise, so the concern (for me at least) is much higher than a DoS.  I'm glad it's addressed in code and it would just be good to mention considerations.

Thank you,
Kathleen

Thanks
Suresh

--

Best regards,
Kathleen

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 14 May 2015 16:02:31 +0000

Kathleen,

> On May 14, 2015, at 8:32 AM, Kathleen Moriarty <[email-masked]> wrote:
> 
> 
> 
> On Wed, May 13, 2015 at 11:59 PM, Suresh Krishnan <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Ron,
> 

I think that overlapping fragment attacks are orthogonal to whether the packet carries GRE or something else. If reassembly happens at the tunnel endpoint, we might end up with a rightly dropped packet. This seems covered in Section 4 of RFC 1858.

What particulars are you thinking about this attack that are specific to GRE?

Thanks,

— Carlos.

> Thank you,
> Kathleen
> 
> 
> Thanks
> Suresh
> 
> 
> 
> 
> --
> 
> Best regards,
> Kathleen
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 14 May 2015 19:44:23 +0000

Kathleen,

The following is an updated Security Considerations Section. Does this work?

                                                                                Ron

Security Considerations
In the GRE fragmentation solution described above, either the GRE payload or the GRE delivery packet can be fragmented.  If the GRE payload is fragmented, it is typically reassembled at its ultimate destination.  If the GRE delivery packet is fragmented, it is typically reassembled at the GRE egress node.

The packet reassembly process is resource intensive and vulnerable to several denial of service attacks.  In the simplest attack, the attacker sends fragmented packets more quickly than the victim can reassemble them.  In a variation on that attack, the first fragment of each packet is missing, so that no packet can ever be reassembled.

Given that the packet reassembly process is resource intensive and vulnerable to denial of service attacks, operators should decide where reassembly process is best performed.  Having made that decision, they should decide whether to fragment the GRE payload or GRE delivery packet, accordingly.

Some IP implementations are vulnerable to the Overlapping Fragment Attack [RFC 1858]. This vulnerability is not specific to GRE and needs to be considered in all environments where IP fragmentation is present. [RFC 3128] describes a procedure by which IPv4 implementations can partially mitigate the vulnerability. [RFC 5722] mandates a procedure by which IPv6-compliant implementations are required to mitigate the vulnerability. The procedure described in RFC 5722 completely mitigates the vulnerability. Operators SHOULD ensure that the vulnerability is mitigated to their satisfaction on equipment that they deploy.

PMTU Discovery is vulnerable to two denial of service attacks (see Section 8 of [RFC1191]<https://tools.ietf.org/html/rfc1191#section-8> for details).  Both attacks are based upon on a malicious party sending forged ICMPv4 Destination Unreachable or ICMPv6 Packet Too Big messages to a host.  In the first attack, the forged message indicates an inordinately small PMTU.  In the second attack, the forged message indicates an inordinately large MTU.  In both cases, throughput is adversely affected.  On order to mitigate such attacks, GRE implementations include a configuration option to disable PMTU discovery on GRE tunnels.  Also, they can include a configuration option that conditions the behavior of PMTUD to establish a minimum PMTU.

<NEW

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 May 2015 20:13:27 +0000

Hi Ron,

Isn’t it true that a DoS attack based on forged PTB messages can be mounted even
if the subject and attacker are both located within the same administrative domain,
i.e., an “insider attack”?

Thanks – Fred
[email-masked]

From: Int-area [mailto:[email-masked]] On Behalf Of Ronald Bonica
Sent: Thursday, May 14, 2015 12:44 PM
To: Kathleen Moriarty; Suresh Krishnan
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; The IESG; [email-masked]
Subject: Re: [Int-area] Kathleen Moriarty's Discuss on draft-ietf-intarea-gre-mtu-04: (with DISCUSS)

Kathleen,

                                                                                Ron

Security Considerations

<NEW

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 14 May 2015 21:11:10 -0400

Hi Ron,

I like the updated text, thank you!

I'm interested to hear the answer to Fred's question too.

Thanks,
Kathleen 

Sent from my iPhone

> On May 14, 2015, at 4:13 PM, "Templin, Fred L" <[email-masked]> wrote:
> 
> Hi Ron,
>  
> PMTU Discovery is vulnerable to two denial of service attacks (see Section 8 of [RFC1191] for details).  Both attacks are based upon on a malicious party sending forged ICMPv4 Destination Unreachable or ICMPv6 Packet Too Big messages to a host.  In the first attack, the forged message indicates an inordinately small PMTU.  In the second attack, the forged message indicates an inordinately large MTU.  In both cases, throughput is adversely affected.  On order to mitigate such attacks, GRE implementations include a configuration option to disable PMTU discovery on GRE tunnels.  Also, they can include a configuration option that conditions the behavior of PMTUD to establish a minimum PMTU.
>  
> <NEW
>  
>  
>

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 15 May 2015 01:49:07 +0000

Hi Kathleen,

Thanks, I will post an updated version of the draft.

Regarding Fred’s question, an attacker can send ICMP PTB to the GRE ingress node. When this happens, the GRE ingress node’s estimation of the PMTU and GMTU become inaccurate. That is why the draft says:

“PMTU Discovery is vulnerable to two denial of service attacks (see Section 8 of [RFC1191] for details). Both attacks are based upon on a malicious party sending forged ICMPv4 Destination Unreachable or ICMPv6 Packet Too Big messages to a host. In the first attack, the forged message indicates an inordinately small PMTU. In the second attack, the forged message indicates an inordinately large MTU. In both cases, throughput is adversely affected. On order to mitigate such attacks, GRE implementations include a configuration option to disable PMTU discovery on GRE tunnels. Also, they can include a configuration option that conditions the behavior of PMTUD to establish a minimum PMTU.”

                                                                               Ron

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Thursday, May 14, 2015 9:11 PM
To: Templin, Fred L
Cc: Ronald Bonica; Suresh Krishnan; [email-masked]; [email-masked]; [email-masked]; [email-masked]; The IESG; [email-masked]
Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-intarea-gre-mtu-04: (with DISCUSS)

Hi Ron,

Thanks,
Kathleen

Sent from my iPhone

On May 14, 2015, at 4:13 PM, "Templin, Fred L" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ron,

Thanks – Fred
[email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; The IESG; [email-masked]<mailto:[email-masked]>

Kathleen,

                                                                                Ron

Security Considerations

<NEW

---

From: Brian Haberman <[email-masked]>
Date: Fri, 15 May 2015 07:58:01 -0400

Hi Kathleen,

On 5/14/15 9:49 PM, Ronald Bonica wrote:
> Regarding Fred’s question, an attacker can send ICMP PTB to the GRE
> ingress node. When this happens, the GRE ingress node’s estimation of
> the PMTU and GMTU become inaccurate. That is why the draft says:
> 
> “PMTU Discovery is vulnerable to two denial of service attacks (see
> Section 8 of [RFC1191] for details). Both attacks are based upon on a
> malicious party sending forged ICMPv4 Destination Unreachable or
> ICMPv6 Packet Too Big messages to a host. In the first attack, the
> forged message indicates an inordinately small PMTU. In the second
> attack, the forged message indicates an inordinately large MTU. In
> both cases, throughput is adversely affected. On order to mitigate
> such attacks, GRE implementations include a configuration option to
> disable PMTU discovery on GRE tunnels. Also, they can include a
> configuration option that conditions the behavior of PMTUD to
> establish a minimum PMTU.”

The problem with Fred's question is that it is a well-known
vulnerability of ICMP in general and has a much broader impact than just
fragmentation and GRE (i.e., this draft). Additionally, I have no idea
why Fred thinks an "insider attack" is any more of an issue than an
arbitrary attack.

Regards,
Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 May 2015 14:39:41 +0000

Hi Brian,

> From: Brian Haberman [mailto:[email-masked]]
> Sent: Friday, May 15, 2015 4:58 AM
> To: Ronald Bonica; Kathleen Moriarty; Templin, Fred L
> Cc: Suresh Krishnan; [email-masked]; [email-masked]; [email-masked]; draft-ietf-intarea-
> [email-masked]; The IESG; [email-masked]

If the original source, ingress and egress are all within the same well
managed  administrative domain, then it would be very advantageous
to use PMTUD instead of probing and/or fragmentation since issues
such as ICMP message loss, multipath and in-the-network fragmentation
are mitigated. But, if source address spoofing is possible within the
administrative domain, then there is opportunity for an insider attack
to disrupt systems that rely on PMTUD.

A fix would be to have the draft mention the ability to spoof source
addresses as a necessary precondition to sustained PTB message
attacks, since attackers that use legitimate source addresses can
be traced. And, the mitigation is for the administrative domain to
employ ingress filtering.

Thanks - Fred
fred.l.templin@boeing,com

---

From: Suresh Krishnan <[email-masked]>
Date: Sat, 16 May 2015 17:13:29 +0000

Hi Fred,

> to disrupt systems that rely on PMTUD.

Right. But Brian's question was if there was anything specific to what 
the draft is proposing. Do you believe that anything in the draft is 
specifically enabling this attack? Or if hosts (routers) implementing 
these drafts are more vulnerable to this attack?

Thanks
Suresh

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 16 May 2015 22:27:19 +0000

Fred,

> On May 15, 2015, at 10:39 AM, Templin, Fred L <[email-masked]> wrote:
> 
> Hi Brian,
> 

Again, like Brian wrote, there is nothing in this draft that enables or directly relates to that attack — or a different way, that attack is broader and not specific to GRE.

— Carlos.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 20 May 2015 04:12:52 +0000

Hi Fred,

On 05/19/2015 05:07 PM, Templin, Fred L wrote:
> The draft is reliant on discovery of the GMTU, which is through PMTUD procedures.
> That being the case, the draft needs to tell the conditions under which PMTUD can
> be relied on. Reliable delivery of PTB messages is one necessary condition. Assurance
> against source address spoofing is another.
>
> Also, I have also said many times that probing with 1280 byte packets is insufficient
> guidance when ECMP or LAG may send data packets along different paths than the
> probe packets. Hence, "MUST" send probes is not useful guidance unless more is
> said about the probing procedure and its interactions with multipath.

As we discussed before, this draft just documents an existing solution 
that has been widely deployed. If you want to bring a better solution to 
the table, that is a fine idea. Please start that discussion in a 
separate thread.

Thanks
Suresh

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 May 2015 21:07:07 +0000

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 20 May 2015 14:31:01 +0000

Hi Suresh,

> From: Suresh Krishnan [mailto:[email-masked]]
> Sent: Tuesday, May 19, 2015 9:13 PM
> To: Templin, Fred L; Carlos Pignataro (cpignata)
> Cc: Brian Haberman; Ronald P. Bonica; Kathleen Moriarty; [email-masked]; [email-masked]; draft-ietf-intarea-
> [email-masked]; [email-masked]; The IESG; [email-masked]
> that has been widely deployed.

That would be an informational; this document is being offered as
standards-track. In Section 3.2, it says:

   "Before activating a GRE tunnel and periodically thereafter, the GRE
   ingress node MUST execute procedures that verify the tunnel's ability
   to carry a 1280-byte IPv6 payload packet from ingress to egress,
   without fragmenting the payload.  Having executed those procedures,
   the GRE ingress node MUST activate or deactivate the tunnel
   accordingly."

But, the GRE ingress is the source of the encapsulated packets; it is not
the source of the payload packets. So, if the payload packets in any way
color the encapsulated packets (e.g., flow label, DSCP, etc.) there is
opportunity for data packets to take different paths than probe packets.
So, saying" MUST" (twice) is asking for standardization of something that
we already know is not going to work in all cases.

> If you want to bring a better solution to

The better solution is to take advantage of standard PMTUD when you
can, and employ fragmentation only when you must. This is why I said:

  "That being the case, the draft needs to tell the conditions under which PMTUD can
    be relied on. Reliable delivery of PTB messages is one necessary condition. Assurance
    against source address spoofing is another."

I will have a new version of AERO out later this AM. I would like to present
Section 3.313 of AERO at the next intarea session.

Thanks - Fred

---

From: Brian Haberman <[email-masked]>
Date: Wed, 20 May 2015 10:58:24 -0400

Hi Ron,

On 5/20/15 10:52 AM, Ronald Bonica wrote:
> Fred,
> 
> Are we all talking about the same draft? The paragraph that you quote
> is not in Section 3.2 of  draft-ietf-intarea-gre-mtu-04.

No, he is referencing a completely different draft...

https://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-07#section-3.2

Regards,
Brian

>> standards- track. In Section 3.2, it says:
>> 
>> "Before activating a GRE tunnel and periodically thereafter, the
>> GRE ingress node MUST execute procedures that verify the tunnel's
>> ability to carry a 1280-byte IPv6 payload packet from ingress to
>> egress, without fragmenting the payload.  Having executed those
>> procedures, the GRE ingress node MUST activate or deactivate the
>> tunnel accordingly."
>>

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 20 May 2015 15:03:23 +0000

Hi Fred,

On 05/20/2015 10:31 AM, Templin, Fred L wrote:
> standards-track.

NACK. The draft is *NOT* being offered as Standards Track. It is 
Informational as shown on both the title page and the tracker under 
"Intended RFC Status".

Does this clarify things?

> we already know is not going to work in all cases.

I do not see this text in the draft in question. I think you may be 
talking about a different draft here. Is this the draft you are talking 
about?

https://tools.ietf.org/html/draft-ietf-intarea-gre-ipv6-07

If so, I suggest leaving the IESG out of further discussions and 
continue discussion on the list with a proper subject line.

> Section 3.313 of AERO at the next intarea session.

Yep. Sounds good.

Thanks
Suresh

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 20 May 2015 15:13:13 +0000

Hi,

> Sent: Wednesday, May 20, 2015 7:58 AM
> To: Ronald Bonica; Templin, Fred L; Suresh Krishnan; Carlos Pignataro (cpignata)
> Cc: Kathleen Moriarty; [email-masked]; [email-masked]; [email-masked]; draft-ietf-
> [email-masked]; The IESG; [email-masked]

Yes, the comments on MTU probing were intended for the GRE IPv6 draft; was
out of the office for several days and away from email, so lost context and got
off track. Sorry.

However, in *this* draft I suggest adding the following trailing sentence to the
final paragraph of the Security Considerations section:

   "These attacks can be mitigated when the ingress and egress are within the
   same well-managed administrative domain, where ingress filtering is employed
   to prevent source address spoofing."

Thanks - Fred

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 20 May 2015 15:46:26 +0000

Hi Fred,

<Trimmed excessive recipient list that keeps tripping the moderation filter>

> out of the office for several days and away from email, so lost context and got

No problem. It happens to the best of us.

>     to prevent source address spoofing."

The draft has already been approved by the IESG. There needs to be a 
high bar to add such text into the draft at this point. If the IESG 
feels strongly about adding such text we can call for WG consensus to do so.

Thanks
Suresh

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 20 May 2015 16:07:17 +0000

Hi Suresh,

> Sent: Wednesday, May 20, 2015 8:46 AM
> To: Templin, Fred L
> Cc: [email-masked]; [email-masked]; Brian Haberman; The IESG

Many thanks for extending the grace. 

> feels strongly about adding such text we can call for WG consensus to do so.

It has only just recently occurred to me that standard PMTUD provides the
best tunnel MTU determination mechanism *in environments where it is
reliable and trustworthy*.  Which is to say, a "well-managed administrative
domain, where ingress filtering is employed to prevent source address
spoofing.". Having gotten off track, I am not going to push hard for this
but it is offered as something the IESG may wish to consider.

Thanks - Fred