Re: Detailedl review of draft-ietf-6man-oversized-header-chain-06
It's normal practice in other WGs I've worked with (e.g, AVT, MMUSIC).
If you name the registry exactly as shown on the IANA page, implementors
can always search for it. A URL is transitory, as the text vs. XML
discussion shows.
On 06/09/2013 8:01 PM, Fernando Gont wrote:
On 09/06/2013 05:13 PM, Brian E Carpenter wrote:
This puzzles me. If the URL is removed prior to publication, I guess one
has to navigate IANA's site, or Google for he registry??
Yes. In the ext-transmit draft, we just put the names of the
registries.
Doesn't that make things ("slightly", if you want) harder for an
implementer?
Cheers,
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Detailedl review of draft-ietf-6man-oversized-header-chain-06
On 07/09/2013 12:01, Fernando Gont wrote:
> On 09/06/2013 05:13 PM, Brian E Carpenter wrote:
>>> This puzzles me. If the URL is removed prior to publication, I guess one
>>> has to navigate IANA's site, or Google for he registry??
>> Yes. In the ext-transmit draft, we just put the names of the
>> registries.
>
> Doesn't that make things ("slightly", if you want) harder for an
> implementer?
I suppose, but IANA would have to solemnly swear never to change
the URL.
Brian
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Detailedl review of draft-ietf-6man-oversized-header-chain-06
On 09/06/2013 05:13 PM, Brian E Carpenter wrote:
>> This puzzles me. If the URL is removed prior to publication, I guess one
>> has to navigate IANA's site, or Google for he registry??
>
> Yes. In the ext-transmit draft, we just put the names of the
> registries.
Doesn't that make things ("slightly", if you want) harder for an
implementer?
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Detailedl review of draft-ietf-6man-oversized-header-chain-06
On 07/09/2013 00:28, Fernando Gont wrote: > On 09/06/2013 08:42 AM, t.petch wrote: >> They are not saying:-( >> >> In >> draft-leiba-cotton-iana-5226bis-03 >> the nearest they come to saying, as far as I can see, how a document >> should reference a registry is >> >> " Providing a URL to precisely identify the registry helps IANA >> understand the request. Such URLs are usually removed from the >> RFC prior to final publication." >> >> Mmm one of those I-Ds which would benefit from discussion were there a >> place designated for discussion. > > This puzzles me. If the URL is removed prior to publication, I guess one > has to navigate IANA's site, or Google for he registry?? Yes. In the ext-transmit draft, we just put the names of the registries. Brian IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
RE: Detailedl review of draft-ietf-6man-oversized-header-chain-06
Tom, I suspect that we will get this wrong and IANA will fix it during their review. Given that we don't know what the reference should look like, there is no sense guessing. Ron > -Original Message- > From: t.petch [mailto:ie...@btconnect.com] > Sent: Friday, September 06, 2013 7:42 AM > To: Brian E Carpenter; Ronald Bonica > Cc: 6man > Subject: Re: Detailedl review of draft-ietf-6man-oversized-header- > chain-06 > > Original Message - > From: "Brian E Carpenter" > To: "Ronald Bonica" > Cc: "6man" > Sent: Thursday, September 05, 2013 9:00 PM > > > Hi Ron, > > > > That looks good to me, thanks! > > > > Regards > >Brian > > > > On 06/09/2013 04:13, Ronald Bonica wrote: > > > Brian, > > > > > > Would the following edits address the issues that you raise? > > > > > > Ron > > > > > >> > > > >> Nit: > > >> > > >> The reference [IANA-PROTO] needs to be verified by IANA - what is > their > > >> preferred URL for the registry? > > >> > > > They are not saying:-( > > In > draft-leiba-cotton-iana-5226bis-03 > the nearest they come to saying, as far as I can see, how a document > should reference a registry is > > " Providing a URL to precisely identify the registry helps IANA > understand the request. Such URLs are usually removed from the > RFC prior to final publication." > > Mmm one of those I-Ds which would benefit from discussion were there a > place designated for discussion. > > Tom Petch > > > > > >> Regards > > >>Brian Carpenter > > >> > > > IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Detailedl review of draft-ietf-6man-oversized-header-chain-06
On 09/06/2013 08:42 AM, t.petch wrote: > > They are not saying:-( > > In > draft-leiba-cotton-iana-5226bis-03 > the nearest they come to saying, as far as I can see, how a document > should reference a registry is > > " Providing a URL to precisely identify the registry helps IANA > understand the request. Such URLs are usually removed from the > RFC prior to final publication." > > Mmm one of those I-Ds which would benefit from discussion were there a > place designated for discussion. This puzzles me. If the URL is removed prior to publication, I guess one has to navigate IANA's site, or Google for he registry?? Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Detailedl review of draft-ietf-6man-oversized-header-chain-06
Original Message - From: "Brian E Carpenter" To: "Ronald Bonica" Cc: "6man" Sent: Thursday, September 05, 2013 9:00 PM > Hi Ron, > > That looks good to me, thanks! > > Regards >Brian > > On 06/09/2013 04:13, Ronald Bonica wrote: > > Brian, > > > > Would the following edits address the issues that you raise? > > > > Ron > > > >> > >> Nit: > >> > >> The reference [IANA-PROTO] needs to be verified by IANA - what is their > >> preferred URL for the registry? > >> They are not saying:-( In draft-leiba-cotton-iana-5226bis-03 the nearest they come to saying, as far as I can see, how a document should reference a registry is " Providing a URL to precisely identify the registry helps IANA understand the request. Such URLs are usually removed from the RFC prior to final publication." Mmm one of those I-Ds which would benefit from discussion were there a place designated for discussion. Tom Petch > >> Regards > >>Brian Carpenter > >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
RE: Detailedl review of draft-ietf-6man-oversized-header-chain-06
Brian, Would the following edits address the issues that you raise? Ron EDITS = OLD> It should be noted that this requirement does not preclude the use of e.g. IPv6 jumbo payloads but instead merely requires that all *headers*, starting from IPv6 base header and continuing up to the upper layer header (e.g. TCP or the like) be present in the first fragment. It should be noted that this requirement does not preclude the use of large payloads but instead but instead merely requires that all headers, starting from IPv6 base header and continuing up to the upper layer header (e.g. TCP or the like) be present in the first fragment. IPv6 Header Chain: The header chain contains an initial IPv6 header, zero or more IPv6 extension headers, and optionally, a single upper-layer header. If an upper-layer header is present, it terminates the header chain. IPv6 Header Chain: The header chain contains an initial IPv6 header, zero or more IPv6 extension headers, and optionally, a single upper-layer header. If an upper-layer header is present, it terminates the header chain; otherwise the "No Next Header" value terminates it. As with all ICMPv6 error/diagnostic messages, deploying Source Address Forgery Prevention filters helps reduce the chances of an attacker successfully performing a reflection attack by sending forged illegal packets with the victim/target's IPv6 address as the IPv6 Source Address of the illegal packet [RFC2827] [RFC3704]. As with all ICMPv6 error/diagnostic messages, deploying Source Address Forgery Prevention filters helps reduce the chances of an attacker successfully performing a reflection attack by sending forged illegal packets with the victim/target's IPv6 address as the IPv6 Source Address of the illegal packet [RFC2827] [RFC3704]. A firewall that performs stateless deep packet inspection, i.e., examines application payload content, might still be unable to correctly process fragmented packets, even if the IPv6 header chain is not fragmented. -Original Message- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Brian E Carpenter > Sent: Wednesday, September 04, 2013 6:21 PM > To: 6man > Subject: Detailedl review of draft-ietf-6man-oversized-header-chain-06 > > The 6man chairs asked me to make an additional detailed review of > draft-ietf-6man-oversized-header-chain-06. > > The main point of the draft is to point out the problems caused by > fragmented header chains and to update RFC 2460 to require that the > entire header chain is in the first fragment. > > This change is an incremental step towards reducing operational > problems with IPv6 extension headers, so it's complementary to draft- > ietf-6man-ext-transmit. It's also an incremental step towards reducing > operational problems with IPv6 fragmentation. > Since the rest of the fragmentation problem remains controversial, I > think it's better to progress draft-ietf-6man-oversized-header-chain > on its own ASAP. (We do have to be realistic though - none of these > improvements will become widely deployed until many IPv6 stacks have > gone through several release cycles.) > > IMHO this document is ready to progress, but I did find 3 minor issues > and a nit. > > Issues: > > In the Introduction: > > >It should be noted that this requirement does not preclude the use > of > >e.g. IPv6 jumbo payloads but instead ... > > Firstly, RFC2675 says "The Jumbo Payload option must not be used in a > packet that carries a Fragment header." > > Secondly using "e.g." as a noun is a bit ugly. I suggest: > > It should be noted that this requirement does not preclude the use of > large payloads but instead ... > > In Terminology: > > > IPv6 Header Chain: > > > > The header chain contains an initial IPv6 header, zero or more > > IPv6 extension headers, and optionally, a single upper-layer > > header. If an upper-layer header is present, it terminates the > > header chain. > > Maybe the "optionally" would be clearer if you also mentioned the "No > Next Header" case by extending the last sentence > > If an upper-layer header is present, it terminates the header chain; > otherwise the "No Next Header" value terminates it. > > I think it would be useful to mention somewhere (perhaps in Security > Considerations) that stateless DPI may still cause problems. > Something like: > > A firewall that performs stateless deep packet inspection, i.e., it > examines application payload content, might still be unable to > correctly process fragmented packets, even if the IPv6 header chain is > not fragmented. > > Nit: > > The reference [IANA-PROTO] needs to be verified by IANA - what is their > preferred URL for the registry? > > Regards >Brian Carpenter > > IETF IPv6 working group mailing list > ipv6@ietf.org > Admini
Re: Detailedl review of draft-ietf-6man-oversized-header-chain-06
Hi Ron, That looks good to me, thanks! Regards Brian On 06/09/2013 04:13, Ronald Bonica wrote: > Brian, > > Would the following edits address the issues that you raise? > > Ron > > EDITS > = > > OLD> > It should be noted that this requirement does not preclude the use of e.g. > IPv6 jumbo payloads but instead merely requires that all *headers*, starting > from IPv6 base header and continuing up to the upper layer header (e.g. TCP > or the like) be present in the first fragment. > NEW> > It should be noted that this requirement does not preclude the use of large > payloads but instead but instead merely requires that all headers, starting > from IPv6 base header and continuing up to the upper layer header (e.g. TCP > or the like) be present in the first fragment. > > OLD> > IPv6 Header Chain: > >The header chain contains an initial IPv6 header, zero or more >IPv6 extension headers, and optionally, a single upper-layer >header. If an upper-layer header is present, it terminates the >header chain. > > NEW> > IPv6 Header Chain: > >The header chain contains an initial IPv6 header, zero or more >IPv6 extension headers, and optionally, a single upper-layer >header. If an upper-layer header is present, it terminates the >header chain; otherwise the "No Next Header" value terminates it. > > OLD> > As with all ICMPv6 error/diagnostic messages, deploying Source Address > Forgery Prevention filters helps reduce the chances of an attacker > successfully performing a reflection attack by sending forged illegal packets > with the victim/target's IPv6 address as the > IPv6 Source Address of the illegal packet [RFC2827] [RFC3704]. > > NEW> > As with all ICMPv6 error/diagnostic messages, deploying Source Address > Forgery Prevention filters helps reduce the chances of an attacker > successfully performing a reflection attack by sending forged illegal packets > with the victim/target's IPv6 address as the > IPv6 Source Address of the illegal packet [RFC2827] [RFC3704]. > > A firewall that performs stateless deep packet inspection, i.e., examines > application payload content, might still be unable to correctly process > fragmented packets, even if the IPv6 header chain is not fragmented. > > > >> -Original Message- >> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of >> Brian E Carpenter >> Sent: Wednesday, September 04, 2013 6:21 PM >> To: 6man >> Subject: Detailedl review of draft-ietf-6man-oversized-header-chain-06 >> >> The 6man chairs asked me to make an additional detailed review of >> draft-ietf-6man-oversized-header-chain-06. >> >> The main point of the draft is to point out the problems caused by >> fragmented header chains and to update RFC 2460 to require that the >> entire header chain is in the first fragment. >> >> This change is an incremental step towards reducing operational >> problems with IPv6 extension headers, so it's complementary to draft- >> ietf-6man-ext-transmit. It's also an incremental step towards reducing >> operational problems with IPv6 fragmentation. >> Since the rest of the fragmentation problem remains controversial, I >> think it's better to progress draft-ietf-6man-oversized-header-chain >> on its own ASAP. (We do have to be realistic though - none of these >> improvements will become widely deployed until many IPv6 stacks have >> gone through several release cycles.) >> >> IMHO this document is ready to progress, but I did find 3 minor issues >> and a nit. >> >> Issues: >> >> In the Introduction: >> >>>It should be noted that this requirement does not preclude the use >> of >>>e.g. IPv6 jumbo payloads but instead ... >> Firstly, RFC2675 says "The Jumbo Payload option must not be used in a >> packet that carries a Fragment header." >> >> Secondly using "e.g." as a noun is a bit ugly. I suggest: >> >> It should be noted that this requirement does not preclude the use of >> large payloads but instead ... >> >> In Terminology: >> >>> IPv6 Header Chain: >>> >>> The header chain contains an initial IPv6 header, zero or more >>> IPv6 extension headers, and optionally, a single upper-layer >>> header. If an upper-layer header is present, it terminates the >>> header chain. >> Maybe the "optionally" would be clearer if you also mentioned the "No >> Next Header" case by extending the last sentence >> >> If an upper-layer header is present, it terminates the header chain; >> otherwise the "No Next Header" value terminates it. >> >> I think it would be useful to mention somewhere (perhaps in Security >> Considerations) that stateless DPI may still cause problems. >> Something like: >> >> A firewall that performs stateless deep packet inspection, i.e., it >> examines application payload content, might still be unable to >> correctly process fragmented packets, even if the IPv6 header chain is >> not fragmented. >> >>
