Subject: Re: Review of draft-ietf-6man-rfc2460bis-05
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed;
 boundary="Apple-Mail=_B0449D3D-3F5E-45DF-B4F8-3BBE0D38E86D";
 protocol="application/pgp-signature"; micalg=pgp-sha512
From: Bob Hinden <bob.hinden@gmail.com>
In-Reply-To: <5CBCFD97-C293-4C86-A851-6295B05D9FAA@jisc.ac.uk>
Date: Mon, 19 Sep 2016 16:14:14 +0300
Message-Id: <084B66B9-2AC5-43DD-B89C-52E252975373@gmail.com>
References: <C75A2D0E-7808-4460-ABC0-AD612484663A@jisc.ac.uk>
 <C453AB9B-3FF4-4706-B5C2-8D747906C088@gmail.com>
 <5CBCFD97-C293-4C86-A851-6295B05D9FAA@jisc.ac.uk>
To: Tim Chown <Tim.Chown@jisc.ac.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/55BFEzMSn_E6dvv3CKC727Ed_zQ>
Cc: "6man@ietf.org" <6man@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
Precedence: list


--Apple-Mail=_B0449D3D-3F5E-45DF-B4F8-3BBE0D38E86D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Tim,

> On Sep 16, 2016, at 4:26 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
>=20
> Hi Bob,
>=20
>> On 30 Aug 2016, at 21:19, Bob Hinden <bob.hinden@gmail.com> wrote:
>>=20
>> Tim,
>>=20
>> Thanks for the detailed review.  Comments below.
>=20
> And thanks for checking them. I=E2=80=99ve looked at the differences =
to -06, which is looking good, and I have only a handful of responses to =
your comments (I=E2=80=99ve deleted the rest, which are fine, for =
brevity).  Some points were also covered off/resolved in the meeting in =
Berlin.

Thanks.

>=20
>>> On Jul 18, 2016, at 12:08 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote
>>>=20
>>> p.8 in the =E2=80=9CIf, as a result=E2=80=A6=E2=80=9D 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.=E2=80=9D? The 2460-bis text implies =
a discard, while 7045 implies that shouldn=E2=80=99t happen unless as a =
result of configured policy?
>>=20
>> 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.
>=20
> I=E2=80=99m still not so sure about this. It seems to be at odds with =
RFC7045, unless done by configured policy.
>=20
> Paragraph 3 of section 2.1 of RFC7045 differentiates between =
forwarding and receiving nodes (destination hosts); perhaps the =E2=80=9CI=
f, as a result=E2=80=A6=E2=80=9D 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.

>=20
>>> p.16 A note about RFC7112 would be best placed after the =E2=80=9CThe =
Fragmentable Part=E2=80=9D paragraph. As it stands, the RFC7112 =
principle (all EHs in the first frag) isn=E2=80=99t mentioned until =
further into the document, on p.17 item (3), and even then 7112 isn=E2=80=99=
t cited.  A note about not creating overlapping fragments could also be =
inserted here, as per RFC5722.
>>=20
>> 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.
>>=20
>> 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=E2=80=99t 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.
>=20
> OK, I appreciate the text might be different if writing afresh as =
opposed to doing an update.
>=20
> 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=E2=80=99t. Other examples of this that don=E2=80=99t 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.

See my response to your comments on rfc4291bis, but I think we are going =
to have to disagree on this one.

>=20
>>> p.16 should we mention here that ND messages should not be =
fragmented, as per RFC6980, section 6?
>>=20
>> No, RFC6980 doesn=E2=80=99t update RFC2460.  There is no other =
mention of ND in this document.
>=20
> Fair point, but I=E2=80=99d 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=E2=80=99s=
 also the one 4861 update that is applicable to 2460 in that it has =
explicit advice wrt fragmentation.

This is the IPv6 specification, I don=E2=80=99t think it is the place to =
list protocols that shouldn=E2=80=99t use IPv6 fragmentation.  It =
should, as you say, go into an ND bis document, and an update to node =
requirements.

>=20
>>> p.18 the =E2=80=9CFragments must not be created=E2=80=A6=E2=80=9D =
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?
>>=20
>> One is about performing fragmentation, the second is about =
reassembly.  It needs to say it in both places.
>>=20
>> =E2=80=9Cslinky=E2=80=9D ?  Did you mean silently?  If so, the text =
at the bottom of page 19 says to discard (and doesn=E2=80=99t say to =
send an ICMP).
>=20
> Sorry, autocorrect at play.  Yes, I meant silently. So the bit (that =
was moved in -06) that says:
>=20
> "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.=E2=80=9D
>=20
> could say "MUST be silently discarded=E2=80=9D. (and cite RFC5722).

=E2=80=9CSilently=E2=80=9D is an odd word here, since the opposite is =
=E2=80=9Cloudly=E2=80=9D.  We aren=E2=80=99t taking about making noise, =
the issue is should an ICMP error should be sent :-)

Instead of trying to define =E2=80=9Csilently=E2=80=9D, I could add =
something like =E2=80=9Cand no ICMP error should be sent=E2=80=9D.  This =
is the only case where ICMP errors are not sent.

>=20
>>> p.20 is the 60 second rule commonly implemented? This seems a very =
high value, and could contribute to DoS effectiveness?
>>=20
>> It sets an upper bound, that is =E2=80=9Cwithin 60 seconds=E2=80=9D.  =
It does not say all fragments must be held for 60 seconds.
>=20
> 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).

I don=E2=80=99t think we have any basis to change this and move to =
Internet Standard.  We don=E2=80=99t 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.

>=20
>>> p.22 is Next Header value 59 used in practice? (Just curious=E2=80=A6 =
it was omitted from RFC7045).
>>=20
>> I am not 100% sure, but think it is used.  But it is not something =
that has been updated.
>=20
> I think Christian Huitema reported that it=E2=80=99s used by Teredo. =
Brian also clarified reference of it in RFC7045, so I think it=E2=80=99s =
fine as is.

Right.

Thanks,
Bob

>=20
> Best wishes,
> Tim
>=20


--Apple-Mail=_B0449D3D-3F5E-45DF-B4F8-3BBE0D38E86D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJX3+SmAAoJEK7rdBF357uoTEwIAJrtKy3mfH+rG+nuwe+DTBGg
F7s4Dv2qSxbc99NmY0v/WkrMV6RZF8OJAkWeg4kk7EUwGP8azr9t3Lyb5IMifuVu
KBFipjn+rV4/MPmqbGmxcFWhWO0q30bmA0xIAn32YvzHd7pwpdfOYoKVdjH9p9iY
jXdBRLIxwZPwu+wz0Pkq0X/2O+UgoTfIsV8cC/cVA7+rr9YpGLI1OJx/GZ0mP+Fp
SjVh0ja9N7YzQ9Aj1HXV5nvbrOWL4J/iEdQKm+2qam9w+Pz+AZgqQbDtCcdnFfUW
3zwivl54MUl2BgIlExOQOlKoJ2XpJKvGGZELAZMS989zqMp7bSMQnHsUC7AphMw=
=Mwwa
-----END PGP SIGNATURE-----

--Apple-Mail=_B0449D3D-3F5E-45DF-B4F8-3BBE0D38E86D--