Subject: Re: Next Header value 59 [was Re: Review of draft-ietf-6man-rfc2460bis-05]

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Sep 2016 11:07:18 +0200

Le 31/08/2016 à 10:30, Tim Chown a écrit :
>> On 30 Aug 2016, at 22:41, [email-masked]
>> <mailto:[email-masked]> wrote:
>>
>> It is used in Teredo. The Teredo bubbles have no payload, hence set
>> payload type to 59.
>
> OK, thanks, that seems a reasonable generic use case, even if there’s
> only one example :)

The minimum size of IPv6 packets often comes in IoT discussion: a 1byte 
payload preceded by an IPv6 header would be useful in constrained 
networks.  "No next header" may not be it, but close.

Alex

>
> But given it’s not in RFC 7045, anyone kind enough to implement the
> advice there won’t necessarily include header 59.
>
> Tim
>
>> Sent from my Windows 10 phone
>>
>> *From: *Brian E Carpenter <mailto:[email-masked]>
>> *Sent: *Tuesday, August 30, 2016 1:40 PM
>> *To: *Bob Hinden <mailto:[email-masked]>; Tim Chown
>> <mailto:[email-masked]>
>> *Cc: [email-masked] <mailto:[email-masked]>
>> *Subject: *Next Header value 59 [was Re: Review of
>> draft-ietf-6man-rfc2460bis-05]
>>
>> On 31/08/2016 08:19, Bob Hinden wrote:
>>
>> ...
>> >> p.22 is Next Header value 59 used in practice? (Just curious… it
>> was omitted from RFC7045).
>> >
>> > I am not 100% sure, but think it is used.  But it is not something
>> that has been updated.
>>
>> It's a curious case, but we didn't mention it in 7045 or ask IANA to
>> include it in
>> http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header
>> because, well, it isn't a header and doesn't require any processing. I
>> think
>> that's OK.
>>
>> Regards
>>      Brian
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked] <mailto:[email-masked]>
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Tim Chown <[email-masked]>
Date: Fri, 16 Sep 2016 11:26:47 +0000

Hi Bob,

> On 30 Aug 2016, at 21:19, Bob Hinden <[email-masked]> wrote:
> 
> Tim,
> 
> Thanks for the detailed review.  Comments below.

And thanks for checking them. I’ve looked at the differences to -06, which is looking good, and I have only a handful of responses to your comments (I’ve deleted the rest, which are fine, for brevity).  Some points were also covered off/resolved in the meeting in Berlin.

>> On Jul 18, 2016, at 12:08 AM, Tim Chown <[email-masked]> wrote
>> 
>> p.8 in the “If, as a result…” paragraph, is the text now contradictory to RFC7045, which says "If a forwarding node discards a packet containing a standard IPv6 extension header, it MUST be the result of a configurable policy and not just the result of a failure to recognise such a header.”? The 2460-bis text implies a discard, while 7045 implies that shouldn’t happen unless as a result of configured policy?
> 
> A node that is required by RFC2460bis to process a header must discard it if it encounters an unrecognized next header value. RFC7045 defines additional reasons why packet might be discarded.

I’m still not so sure about this. It seems to be at odds with RFC7045, unless done by configured policy.

Paragraph 3 of section 2.1 of RFC7045 differentiates between forwarding and receiving nodes (destination hosts); perhaps the “If, as a result…” paragraph on p.8 should do the same?

>> p.16 A note about RFC7112 would be best placed after the “The Fragmentable Part” paragraph. As it stands, the RFC7112 principle (all EHs in the first frag) isn’t mentioned until further into the document, on p.17 item (3), and even then 7112 isn’t cited.  A note about not creating overlapping fragments could also be inserted here, as per RFC5722.
> 
> This was a case where I incorporated the ideas of the update and kept the terminology as close as possible as the original.  There were several updates that had to be incorporated.
> 
> I continue to think it reads OK.  The text you mention is on the next page.  A subtle change here is that this text doesn’t allow overlapping fragments to be created, unlike the origional, as the text separates the rules for the first and subsequent fragments.  The non-overlaping text is later because it should only happen if sent by a non-conforming or malicious sender.

OK, I appreciate the text might be different if writing afresh as opposed to doing an update.

There was a general question here raised in Berlin as to whether newer RFCs like RFC7112 should cited in the main body of 2460-bis, as would be the case here for note (3) in Section 4.5, or whether the references are only made in the Appendix listing the changes. Some do, like RFC7045, but some don’t. Other examples of this that don’t are RFC6564, RFC5722, RFC6946, which are in Appendix B but not the main body.  Personally, I think for clarity for the reader, they should be in the main text.

>> p.16 should we mention here that ND messages should not be fragmented, as per RFC6980, section 6?
> 
> No, RFC6980 doesn’t update RFC2460.  There is no other mention of ND in this document.

Fair point, but I’d argue that we have gathered other important advice/requirements wrt to fragmentation into 2460-bis, and a pointer here for fragmentation of ND messages could be valuable for readers. I agree it would be more appropriate in any 4861-bis that happens in the future, and it is a formal update to 4861, but it’s also the one 4861 update that is applicable to 2460 in that it has explicit advice wrt fragmentation.

>> p.18 the “Fragments must not be created…” line is a duplication of the last paragraph on p.19.  Move that larger para forward?   Also perhaps note the requirement to slinky discard, as per RFC5722?
> 
> One is about performing fragmentation, the second is about reassembly.  It needs to say it in both places.
> 
> “slinky” ?  Did you mean silently?  If so, the text at the bottom of page 19 says to discard (and doesn’t say to send an ICMP).

Sorry, autocorrect at play.  Yes, I meant silently. So the bit (that was moved in -06) that says:

"If any of the fragments being reassembled overlaps with any other
      fragments being reassembled for the same packet, reassembly of
      that packet must be abandoned and all the fragments that have been
      received for that packet must be discarded.”

could say "MUST be silently discarded”. (and cite RFC5722).

>> p.20 is the 60 second rule commonly implemented? This seems a very high value, and could contribute to DoS effectiveness?
> 
> It sets an upper bound, that is “within 60 seconds”.  It does not say all fragments must be held for 60 seconds.

This was asked in Berlin; I recall Tim Winters reported that in his experience of tests run, common platforms do obey the 60 second requirement (whether or not that may be an issue for DoS in a high-speed network).

>> p.22 is Next Header value 59 used in practice? (Just curious… it was omitted from RFC7045).
> 
> I am not 100% sure, but think it is used.  But it is not something that has been updated.

I think Christian Huitema reported that it’s used by Teredo. Brian also clarified reference of it in RFC7045, so I think it’s fine as is.

Best wishes,
Tim

---

From: Bob Hinden <[email-masked]>
Date: Mon, 19 Sep 2016 16:14:14 +0300

Tim,

> On Sep 16, 2016, at 4:26 AM, Tim Chown <[email-masked]> wrote:
> 
> Hi Bob,
> 

Thanks.

> Paragraph 3 of section 2.1 of RFC7045 differentiates between forwarding and receiving nodes (destination hosts); perhaps the “If, as a result…” paragraph on p.8 should do the same?

RFC7045 is providing guidance for forwarding nodes that look at Extension headers.  The text in RFC2460 is about destination nodes.  Specifically earlier in this section it says:

   With one exception, extension headers are not processed by any node
   along a packet's delivery path, until the packet reaches the node (or
   each of the set of nodes, in the case of multicast) identified in the
   Destination Address field of the IPv6 header.  Note: If an
   intermediate forwarding node examines an extension header for any
   reason, it must do so in accordance with the provisions of [RFC7045].

The first sentence sets the context.

> There was a general question here raised in Berlin as to whether newer RFCs like RFC7112 should cited in the main body of 2460-bis, as would be the case here for note (3) in Section 4.5, or whether…

See my response to your comments on rfc4291bis, but I think we are going to have to disagree on this one.

> Fair point, but I’d argue that we have gathered other important advice/requirements wrt to fragmentation into 2460-bis, and a pointer here for fragmentation of ND messages could be valuable for rea…

This is the IPv6 specification, I don’t think it is the place to list protocols that shouldn’t use IPv6 fragmentation.  It should, as you say, go into an ND bis document, and an update to node requirements.

> could say "MUST be silently discarded”. (and cite RFC5722).

“Silently” is an odd word here, since the opposite is “loudly”.  We aren’t taking about making noise, the issue is should an ICMP error should be sent :-)

Instead of trying to define “silently”, I could add something like “and no ICMP error should be sent”.  This is the only case where ICMP errors are not sent.

> This was asked in Berlin; I recall Tim Winters reported that in his experience of tests run, common platforms do obey the 60 second requirement (whether or not that may be an issue for DoS in a hig…

I don’t think we have any basis to change this and move to Internet Standard.  We don’t want to invalidate any implementations.  Then there is the whole issue of what to change it to.  30 seconds, 1 seconds, .1 second, etc.  I see it as an issue for how manage a fragment reassembly queue, this is more complicated than a timeout number.

This falls into the category of resource management in implementations.  I think there is lots of advice on that topic in a range of documents, and it is much broader than how long single fragments are kept around.

> I think Christian Huitema reported that it’s used by Teredo. Brian also clarified reference of it in RFC7045, so I think it’s fine as is.

Right.

Thanks,
Bob

---

From: Tim Chown <[email-masked]>
Date: Mon, 19 Sep 2016 14:55:47 +0000

Hi Bob,

> On 19 Sep 2016, at 14:14, Bob Hinden <[email-masked]> wrote:
> 
> Tim,
> 

Fair point.

Would it help ensure clarity if "If, as a result of processing a header, a node is required” is changed to "If, as a result of processing a header, the Destination node is required”?

(which is the same language then as the sentence immediately after the text you quoted above, which says "At the Destination node, normal demultiplexing…”)

> See my response to your comments on rfc4291bis, but I think we are going to have to disagree on this one.

OK, that’s fine. I may have had it drummed into me a little too much to always cite references :)

> This is the IPv6 specification, I don’t think it is the place to list protocols that shouldn’t use IPv6 fragmentation.  It should, as you say, go into an ND bis document, and an update to node requ…

OK. And thanks for the implicit reminder :)

> Instead of trying to define “silently”, I could add something like “and no ICMP error should be sent”.  This is the only case where ICMP errors are not sent.

Yes, that would be fine. A reader would probably draw that conclusion given the three or more cases of discard above all say “and return an ICMP message”, but I think it’s good to spell it out explicitly, assuming that’s what implementations are doing.

> This falls into the category of resource management in implementations.  I think there is lots of advice on that topic in a range of documents, and it is much broader than how long single fragments…

Agreed.  And as a side note it might be useful for someone to pull those pieces together in one draft.

Thanks,
Tim

---

From: Bob Hinden <[email-masked]>
Date: Tue, 20 Sep 2016 15:47:01 +0300

Tim,

> On Sep 19, 2016, at 5:55 PM, Tim Chown <[email-masked]> wrote:
> 
> Hi Bob,
> 
>> 

….

> (which is the same language then as the sentence immediately after the text you quoted above, which says "At the Destination node, normal demultiplexing…”)

I think that is fine.

….

> Agreed.  And as a side note it might be useful for someone to pull those pieces together in one draft.

It could also go in Node Requirements.

Thanks,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Sep 2016 10:42:21 +1200

I realised that we probably have to discuss this further. There are two
places where rfc2460bis explicitly allows a covert channel because of
No Next Header:

> 4.5.  Fragment Header
...
>       The Fragmentable Part consists of the rest of the packet after the
>       upper-layer header or after any header (i.e., initial IPv6 header
>       or extension header) that contains a Next Header value of No Next
>       Header.
...
> 4.7.  No Next Header
> 
>    The value 59 in the Next Header field of an IPv6 header or any
>    extension header indicates that there is nothing following that
>    header.  If the Payload Length field of the IPv6 header indicates the
>    presence of octets past the end of a header whose Next Header field
>    contains 59, those octets must be ignored, and passed on unchanged if
>    the packet is forwarded.

Do we really want to allow this? Do we know whether current firewalls
tolerate it?

If we keep this, I think some words about the covert channel are needed
in the Security Considerations.

And looking at the Security Considerations, I don't think they are
sufficient anyway. At the least we should refer to other work, not
just IPSec.

Regards
   Brian

On 01/09/2016 08:32, Brian E Carpenter wrote:
> On 31/08/2016 20:30, Tim Chown wrote:
>> On 30 Aug 2016, at 22:41, [email-masked]<mailto:[email-masked]> wrote:
>>
>> It is used in Teredo. The Teredo bubbles have no payload, hence set payload type to 59.
>>
>> OK, thanks, that seems a reasonable generic use case, even if there’s only one example :)
>>
>> But given it’s not in RFC 7045, anyone kind enough to implement the advice there won’t necessarily include header 59.
> 
> Actually it is mentioned in 7045 but intentionally not listed in the IANA registry:
>    "This list excludes type 59, No Next Header, [RFC2460], which is not
>    an extension header as such."
> 
> Packets with "No Next Header" followed by additional bytes are allowed by RFC2460,
> but would be very suspect to any firewall, I would think.
> 
>     Brian
> 
>>
>> Tim
>>
>> From: Brian E Carpenter<mailto:[email-masked]>
>> Sent: Tuesday, August 30, 2016 1:40 PM
>> To: Bob Hinden<mailto:[email-masked]>; Tim Chown<mailto:[email-masked]>
>> Cc: [email-masked]<mailto:[email-masked]>
>> Subject: Next Header value 59 [was Re: Review of draft-ietf-6man-rfc2460bis-05]
>>
>> It's a curious case, but we didn't mention it in 7045 or ask IANA to include it in
>> because, well, it isn't a header and doesn't require any processing. I think
>> that's OK.
>>
>> Regards
>>      Brian
>>
>> [email-masked]<mailto:[email-masked]>

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 20 Sep 2016 15:58:13 -0700

Tuesday, September 20, 2016 3:42 PM, Brian E Carpenter wrote:
> Do we really want to allow this?

No. We should be chasing covert channels and eliminating them. AFAIK, our implementation of Teredo does not send any extra bytes after the "no next header."
 
> Do we know whether current firewalls tolerate it?

No idea. But they probably should not.

I would suggest replacing the text by "If the Payload Length field of the IPv6 header indicates the presence of octets past the end of a header whose Next Header field contains 59, the packet should be rejected." Or something like that.

> sufficient anyway. At the least we should refer to other work, not

We could add some text about packet length discrepancy. Something like "Firewalls and other devices should detect the presence of a hidden communication channel if the length of the concatenated headers does not match the length of the IPv6 payload. Such packets MAY be rejected."

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Sep 2016 06:00:23 -0300

Hi, Brian,

> Do we really want to allow this? 

I'd say: no.

> Do we know whether current firewalls tolerate it?

My take: such fws simply bloc the packet as a result of NH=59. I'd bet
they don't care abut the specific case where there are extra bytes (as
described).

> in the Security Considerations.

This is a bogus packet. Let's keep things simple.

> sufficient anyway. At the least we should refer to other work, not

+1.

P.S.: When it comes to covert channels, there are quite a few other
options: e.g. think about EHs with unknown options, or EHs with PadN
options in which the padding bytes are non-zero.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Tim Chown <[email-masked]>
Date: Wed, 21 Sep 2016 09:17:23 +0000

Hi,

> On 21 Sep 2016, at 10:00, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Brian,
> 

What other than Teredo might genuinely use NH=59?

> options in which the padding bytes are non-zero.

Well yes; it was clear from using scapy to send packets for the “EHs in the wild” tests we ran that there’s scope to do a variety of “covert” things in EHs. I’m sure Fernando could easily add options to his EH test scripts to do likewise, if he chose to do so. I don’t recall the required content of PadN padding is formally specified or restricted?

Tim

---

From: Bob Hinden <[email-masked]>
Date: Wed, 21 Sep 2016 13:54:17 +0300

Brian,

> On Sep 21, 2016, at 1:42 AM, Brian E Carpenter <[email-masked]> wrote:
> 

Let me push back a little.  This but one of probably an infinite vehicles for a covert channel.  For example, looking at the IANA protocol number registries, there are many values that only point to a person (that is, not a document).  Each of these could be used for covert communication.  What is the value of fixing this?  I don’t think it is very useful.

If someone wants to do effective covert communication, they will do it so it looks like normal traffic, not use an esoteric protocol number like 59.

Lastly to the issue of extra bytes at the end of a packet, it’s my understanding that there may be some implementations due to hardware performance optimizations, may send a few extra bytes at the end of the packet with to no ill effects.  If we start creating rules to drop packets like this because it might be a covert channel, we may well break existing implementations.

Bob

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Sep 2016 08:02:50 -0300

Hi, Bob,

On 09/21/2016 07:54 AM, Bob Hinden wrote:
>>> header.  If the Payload Length field of the IPv6 header indicates
>>> the presence of octets past the end of a header whose Next Header
>>> field contains 59, those octets must be ignored, and passed on
>>> unchanged if the packet is forwarded.
>> 
>> Do we really want to allow this? Do we know whether current
>> firewalls tolerate it?
>> 
>> If we keep this, I think some words about the covert channel are
>> needed in the Security Considerations.
> 
> Let me push back a little.  This but one of probably an infinite
> vehicles for a covert channel.  For example, looking at the IANA
> protocol number registries, there are many values that only point to
> a person (that is, not a document).  Each of these could be used for
> covert communication.  What is the value of fixing this?  I don’t
> think it is very useful.

FWIW, I'd fix this as a bogus packet, not because of the hope of
stopping covert channels (I agree with you on this one).

> Lastly to the issue of extra bytes at the end of a packet, it’s my
> understanding that there may be some implementations due to hardware
> performance optimizations, may send a few extra bytes at the end of
> the packet with to no ill effects.  If we start creating rules to
> drop packets like this because it might be a covert channel, we may
> well break existing implementations.

Such packets would have padding at layer-2, but the IPv6 length should
still be correct. i.e., if a packet has NH=59 but the Total Length
reports that there's stuff past the "no header", it must be bogus.

Thanks,

---

From: Bob Hinden <[email-masked]>
Date: Wed, 21 Sep 2016 15:10:54 +0300

Fernando,

> On Sep 21, 2016, at 2:02 PM, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Bob,
> 

Two other thoughts.

I would be good to understand how we got the text:

      If the Payload Length field of the IPv6 header
      indicates the presence of octets past the end of a header whose
      Next Header field contains 59, those octets must be ignored, and
      passed on unchanged if the packet is forwarded.

I don’t know, maybe someone can do some searches.  I suspect there may have been some reason behind it.

I also think this topic falls into the quote attributed to Jon Postel (from RFC760):

   "Be liberal in what you accept, and conservative in what you send”

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Sep 2016 08:52:19 +1200

>> stopping covert channels (I agree with you on this one).

Yes, stopping all covert channels would be a Quixotic task, but this
one seems blatant. However, it is also an obvious vector for a buffer
overflow attack, so there is every reason to tackle it.

> I don’t know, maybe someone can do some searches.  I suspect there may have been some reason behind it.

I have a vague idea that there was a thought of using it for experiments, i.e. put
a header or payload there regardless. But we have experimental values 253 and 254
assigned for exactly that purpose now.

>    "Be liberal in what you accept, and conservative in what you send”

But firewalls don't follow that, do they?

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Sep 2016 18:00:34 -0300

> overflow attack, so there is every reason to tackle it.

Fully agree.

> But firewalls don't follow that, do they?

FWs, NIDSes...you name them.

Besides:
http://www.cs.dartmouth.edu/~sergey/langsec/papers/postel-patch-draft.pdf

Thanks,
Fernando

---

From: 神明達哉 <[email-masked]>
Date: Wed, 21 Sep 2016 18:31:47 -0700

At Mon, 19 Sep 2016 16:14:14 +0300,
Bob Hinden <[email-masked]> wrote:

> >> It sets an upper bound, that is “within 60 seconds”.  It does not
> >> say all fragments must be held for 60 seconds.
> >
> > This was asked in Berlin; I recall Tim Winters reported that in
> > his experience of tests run, common platforms do obey the 60
> > second requirement (whether or not that may be an issue for DoS in
> > a high-speed network).

If this is DoS by having the receiving node exhaust memory for a huge
number of fragments, BSD variants (I believe all flavors of them) have
a simple defense against it: limiting the total number of fragments to
be held for reassembly and the number of original packets reassembled
from fragments.  It's actually derived from old IPv4 implementations,
so it should be a pretty common practice for other systems, too.

--
JINMEI, Tatuya

---

From: [email-masked]
Date: Wed, 21 Sep 2016 13:59:46 +0200

> reports that there's stuff past the "no header", it must be bogus.

I'd certainly like to understand what the intention was before declaring it bogus.

Best regards,
Ole

---

From: [email-masked]
Date: Wed, 21 Sep 2016 08:53:31 +0200

>>   contains 59, those octets must be ignored, and passed on unchanged if

I had a walk through the archives but couldn't find anything.
I am quite sure there was a purpose to this text, but I can't quite figure out what. Anyone remembers?

Cheers,
Ole

---

From: [email-masked]
Date: Wed, 21 Sep 2016 10:51:01 +0200

Cheers,
Ole

---

From: Tim Chown <[email-masked]>
Date: Thu, 22 Sep 2016 08:09:19 +0000

Hi Jinmei,

> On 22 Sep 2016, at 02:31, 神明達哉 <[email-masked]> wrote:
> 

Yes, that was the concern. It just seems a very generous value. 

I guess I should ask whether, given this seems to be common practice, we might add a sentence to the relevant paragraph in 4.5, something like:

Old:

"If insufficient fragments are received to complete reassembly of a
      packet within 60 seconds of the reception of the first-arriving
      fragment of that packet, reassembly of that packet must be
      abandoned and all the fragments that have been received for that
      packet must be discarded.  If the first fragment (i.e., the one
      with a Fragment Offset of zero) has been received, an ICMP Time
      Exceeded -- Fragment Reassembly Time Exceeded message should be
      sent to the source of that fragment.”

New:

"If insufficient fragments are received to complete reassembly of a
      packet within 60 seconds of the reception of the first-arriving
      fragment of that packet, reassembly of that packet must be
      abandoned and all the fragments that have been received for that
      packet must be discarded.  If the first fragment (i.e., the one
      with a Fragment Offset of zero) has been received, an ICMP Time
      Exceeded -- Fragment Reassembly Time Exceeded message should be
      sent to the source of that fragment. To protect against potential memory 
      exhaustion, a node MAY choose to limit the number of fragments held 
      for reassembly, independently of the 60 second timer.”

?

Then it is clear there is no assumption that all fragments will be held for that period, but it wouldn’t affect the type of conformance tests that Tim would run.

Tim

---

From: Bob Hinden <[email-masked]>
Date: Thu, 22 Sep 2016 12:32:23 +0300

Tim,

> Then it is clear there is no assumption that all fragments will be held for that period, but it wouldn’t affect the type of conformance tests that Tim would run.

You are proposing to add:

     To protect against potential memory
     exhaustion, a node MAY choose to limit the number of fragments held
     for reassembly, independently of the 60 second timer.

I don’t see it doing any harm, but I am not sure if fixes a problem.  This is the IPv6 specification that describes the protocol over the wire and procedures to achieve interoperability.  It was never intended to be a complete implementation guide.  I think this goes to far in to describing what an implementation should do.

If someone else thinks it’s important I will add it, but I am not convinced at the moment :-)

Thanks,
Bob

---

From: 神明達哉 <[email-masked]>
Date: Fri, 23 Sep 2016 09:52:49 -0700

At Thu, 22 Sep 2016 12:32:23 +0300,
Bob Hinden <[email-masked]> wrote:

> > Then it is clear there is no assumption that all fragments will be
> > held for that period, but it wouldn’t affect the type of
> > conformance tests that Tim would run.
>
> I don’t see it doing any harm, but I am not sure if fixes a problem.
> This is the IPv6 specification that describes the protocol over the
> wire and procedures to achieve interoperability.  It was never
> intended to be a complete implementation guide.  I think this goes
> to far in to describing what an implementation should do.
>

I'm inclined to not be too verbose in this case.  But if we want to
add a note about this DoS vector, we might mention the vector in the
security considerations section, not as part of Section 4.5 (for the
fragment header processing).  In any case, describing a specific
defense measure is probably too much.

--
JINMEI, Tatuya