Fred,

On 18/11/2014 15:24, Fred Baker (fred) wrote:
> On Nov 17, 2014, at 5:46 PM, Erik Nordmark <nordmark@acm.org>
> wrote:
> 
>> On 11/17/14 5:25 PM, Fred Baker (fred) wrote:
>>> I don’t find the text in RFC 791 or 2460; maybe IP is not
>>> required to be robust. However, I will argue that the
>>> following text from RFC 2460 section 4 fails to support
>>> the principle:
>>>> If, as a result of processing a header, a node is
>>>> required to proceed to the next header but the Next
>>>> Header value in the current header is unrecognized by
>>>> the node, it should discard the packet and send an ICMP
>>>> Parameter Problem message to the source of the packet,
>>>> with an ICMP Code value of 1 ("unrecognized Next Header
>>>> type encountered") and the ICMP Pointer field
>>>> containing the offset of the unrecognized value within
>>>> the original packet.  The same action should be taken
>>>> if a node encounters a Next Header value of zero in any
>>>> header other than an IPv6 header.
>>> The net effect is that, should one wish to deploy a new
>>> extension header, one cannot reliably use it until every
>>> host and router it will traverse has been updated, which
>>> is in effect “never”. The words “should discard the
>>> packet and” should, in my opinion, be removed, following
>>> the IPv4 model of ignoring an unknown option (RFC 1122
>>> section 3.2.1.8, second paragraph). Send an ICMP if you
>>> like, but don’t prevent communication.
>> Fred,
>> 
>> I haven't re-read RFC 2460 but I'm pretty sure that the
>> preamble "is required to proceed" above is supposed to
>> handle this. A router is only "required to proceed" past
>> the IPv6 header if - the packet is explicitly addressed to
>> (one of) the router's IPv6 address(es) (which was the case
>> for routing headers) - the packet has a hop-by-hop options
>> header
>> 
>> But a router must implement HBH. And if the packet has a
>> routing header then there is not need for the router to
>> look at the header after the RH unless segments left = 0
>> (i.e., the router is at the final destination of the RH
>> path).
>> 
>> So if the world only has hosts and routers I think the text
>> if fine.
> 
> Well, I’m not so sure. I’d suggest you re-read
> https://tools.ietf.org/html/rfc2460#section-4
> 
> It doesn’t refer to a router or a host; it refers to a node.

Well yes, but having spoken quite recently to Mr Deering about
this topic, it is quite clear that in his mind middleboxes of
any kind are evil and were assumed not to exist when IPv6 was
designed, and RFC 2460 makes that assumption throughout.

However, RFC 7045 explicitly discusses this topic and does
discuss the question of unknown headers. (We declared unknown
options out of scope.)

Among many other things, we say

"RFC 2460 requires destination hosts to discard packets
containing unrecognised extension headers.  However,
intermediate forwarding nodes SHOULD NOT do this, since that
might cause them to inadvertently discard traffic using a
recently standardised extension header not yet recognised by the
intermediate node.  The exceptions to this rule are discussed next."

So, I am not disagreeing with your point, just observing that it
is partially covered already by RFC 7045. And options are
discussed in draft-gont-6man-ipv6-opt-transmit.

I'm not sure this can be covered by an erratum, but please look
at 7045 and Fernando's draft anyway.

Regards

    Brian

> The context is not “going beyond the IPv6 header to
> TCP-or-whatever”. It is “I processed the base IPv6 header or
> some extension header, for whatever reason I need to go to
> the next extension header, and I don’t understand it.”
> 
> Extension headers invariable have as their first two bytes:
> 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  Next Header  |  Hdr Ext
> Len  | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> So there is no question of being able to step past the next
> header until it finds something it understands. It knows
> where the “next header” identifier and the header length are.
> The thing that raises the point, to me, is the Segment
> Routing Extension Header (which should perhaps be an option
> in the Routing Header, and about which there are several
> opinions). At this point, the ultimate recipient of a message
> with that extension has to be SRH-capable, or the penultimate
> hop has to remove the thing, because of this text.
> 
> Now, everyone gets their own opinion of SRH, and personally
> I’m not sure I see why the considerations of RFC 5095 don’t
> apply. None-the-less, I’m wondering what happens when we do
> get a new extension header. I’m not sure it’s good. If we are
> trying to deploy a new extension header and it is presented
> to an unupdated system, we get a parameter problem, not a
> robust response.
> 
>> But in a world with middle-boxes the text can be
>> misinterpreted to also apply to those middleboxes. AFAIK
>> that was not the intent. Thus I think a clarification is in
>> order.
> 
> What clarification would you suggest? That the packet be
> dropped, or that the node that thinks it needs to continue on
> its way (perhaps a router addressed in the destination
> address looking to see if a Routing Header is present, for
> example, or a firewall that mistakenly thinks that combing
> through TCP headers makes sense) should attempt to skip the
> header?
> 
> There is, of course, a security consideration. An interesting
> attack would be to use an unknown header option, or an
> incorrect length, to send the system that receives it into
> la-la-land. We already have that attack in the extensions and
> options we have.
> 
>> Thanks, Erik
>> 
>>> Note that this is not true of an option carried within an
>>> extension header.
>>> https://tools.ietf.org/html/rfc2460#section-4.2 gives the
>>> sender the option of declaring that an option may be
>>> skipped or must result in packet discard, and gives three
>>> cases for possible notification of the sender.
>>> 
>>> Can someone give me a good reason to NOT file that
>>> erratum?
>>> 
>>> 
>>> --------------------------------------------------------------------
>>>  IETF IPv6 working group mailing list ipv6@ietf.org 
>>> Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6 
>>> --------------------------------------------------------------------
>>> 
>> --------------------------------------------------------------------
>>  IETF IPv6 working group mailing list ipv6@ietf.org 
>> Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6 
>> --------------------------------------------------------------------
>> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org 
> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------