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 protected]> > wrote: > > 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 protected] > > From: Int-area [mailto:[email protected]] On Behalf Of Ronald Bonica > Sent: Thursday, May 14, 2015 12:44 PM > To: Kathleen Moriarty; Suresh Krishnan > Cc: [email protected]; [email protected]; > [email protected]; > [email protected]; The IESG; > [email protected] > Subject: Re: [Int-area] Kathleen Moriarty's Discuss on > draft-ietf-intarea-gre-mtu-04: (with DISCUSS) > > 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] 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 > > >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
