Re: TSVART review of draft-ietf-6man-deprecate-atomfrag-generation

[Joe Touch <[e-mail]>]

Hi, Fernando,


On 8/29/2016 3:05 PM, Fernando Gont wrote:
> On 08/28/2016 01:33 PM, Joe Touch wrote:
>> Hi, Fernando,
>>
>> First, I'd like to note something more important about this doc - the
>> abstract itself argues that this change should update the core IPv6
>> spec. Given that is already well underway, why is this document even
>> needed?
> The document says it clearly: "documenting the
>    motivation for removing this functionality in the revision of the
>    core IPv6 protocol specification."
>
> You just don't remove a feature from a spec silently, without a
> rationale. And the place to include the rationale wasn't rfc2460bis --
> hence this dcument.

I don't agree. RFC2460bis should not need a roadmap to explain all of
the associated changes and their rationales. That should be in 2460bis.

Otherwise, changes need to be made incrementally - that's a lot of extra
load on the IETF and a lot of complexity to figure out why things are
the way the end up.


>
>
>
>
>
>>>> The impact of this change does not appear to have been explored. Section
>>>> 3 ends with a claim that links where this translation issue would be a
>>>> problem are rare, but there is no evidence presented as to whether
>>>> current RFC 6145 translators would be capable of complying with the
>>>> changes in this doc, e.g., to be able to generate IPv4 IDs as needed.
>>>> I.e., this document needs to update RFC6145 Sec 5.1 to require that IPv4
>>>> ID generation MUST be supported (and used), rather than MAY.
>>> RFC 6145 has been revised as RFC7915.
>> The second sentence of this draft cites 6145. You raise a good point,
>> but given 7915 obsoletes 6145 (rather than updating it), all references
>> throughout should then refer to 7915 instead.
> Not really. We're documenting why this feature is being removed -- hence
> there's a place for referencing RFC6145 ("state of affairs before any
> updates") and RFC7915.
>
> All references to RFC6145 are of the form "legacy translators", or
> "RFC6145 was...".

I don't think it's useful to refer in this doc to a spec that is already
obsoleted.

This is further reason why it's not useful to issue separate change
docs. It gets confusing as to what you're arguing and why.

>
>>> The document concludes that the translator should create IPv4 IDs rather
>>>> than relying on atomic fragments as a source of that information (as per
>>>> RFC2460) because there is no benefit, but are two reasons why this
>>>> method is directly hazardous as well: 1) RFC 2460 does not require that
>>>> the IPv6 ID field is generated to ensure that the low 16-bits are unique
>>>> as required for use as IPv4 IDs as defined in RFC 6145, and 2) RFC 6145
>>>> translation could result in collisions where two distinct IPv6
>>>> destinations are translated into the same IPv4 address, such that IDs
>>>> that might have been generated to be unique in the IPv6 context could
>>>> end up colliding when used in the translated IPv4 context. I.e., this
>>>> does not require ECMP as implied in Section 3.
>>> mmm.. not sure I follow. When we refer to ECMP in Section 3 we're
>>> actually describing the only possible scenario in which relying on the
>>> ID in the Frag Header could be of use (i.e., possibly result in lower
>>> collision rates).
>> I'm not speaking of when the ID in the Frag Header can be useful. I'm
>> speaking of other more likely cases where using the low 16 bits of the
>> IPv6 ID field can generate IPv4 collisions.
> So you argue in favor of adding an extra bullet noting that RFC2460 does
> not require the lower 16 bits to be unique? (just double-checking). If
> so, fine with me.

Yes - specifically, 2460 does not require that the lower 16 bits of the
ID are generated in a way that would comply with the expectations of
using just those bits for IPv4.

>
>>>> Minor issues:
>>>>
>>>> IMO, it remains unwise to continue to imply that networks should treat
>>>> packets with fragment headers as an attack. Fragmentation support is
>>>> critical to tunneling (see draft-ietf-intarea-tunnels) and we need to
>>>> find ways to support their use safely. The text should be edited to
>>>> explain that the primary motivation here is to avoid generating
>>>> erroneous IPv4 ID fields, rather than to react to the incorrect
>>>> classification of fragment headers as incompatible with the Internet.
>>> Not sure what you mean.
>>>
>>> We're not implying that packets employing FH are an attack. FWIW, I
>>> don't personally think so. We do think that, when employing
>>> fragmentation, you open the door to a number of attack vectors. See
>>> e.g., Section 5 of draft-gont-v6ops-ipv6-ehs-packet-drops-03.txt.
>> Some of the attacks described are based on the widespread dropping of a
>> valid IPv6 packet with valid IPv6 extension headers.
>>
>> IMO, it is important to be clear that this makes users of a legitimate
>> IPv6 capability vulnerable because of incorrect behavior of routers. 
> 1) The attack I referenced is just one possible attack. If you employ
> fragmentation, an atacker could just send forged packets meant to cause
> collisions of frag IDs such that your packets are dropped -- clearly
> employing an extra feature (as in this case), creates an attack vector.
There are many possible attacks but you focus on the one where routers
drop packets because they have frag EHs.

> 2) The bahavior in routers is a policy. We may not like it. BUt it's a
> policy, not incorrect behavior.
EHs are not optional in RFC2460. Dropping because you see them is not
policy - it forces the router to fail to support a required feature of IPv6.


>
>> It
>> seems important to remind readers that the real issue here is the
>> non-compliant routers. If that information isn't present, it implies
>> that it is the use of the EHs that is incorrect and should be avoided in
>> general. That's impossible for fragmentation - it is a critical
>> capability without which tunneling cannot exist.
> Fragmentation has been considered harmful for ages.

And is finally being understood as fundamentally necessary for tunneling.

>  And yes, we're
> saying that if you *do not need it*, you shouldn't use it.
Yes, if you don't need tunnels, you shouldn't use them either, but that
doesn't mean tunnels shouldn't be used in general.


>
>>>> The claim that links with IPv6 MTUs smaller than 1260 are rare needs to
>>>> be supported with evidence. I appreciate that such evidence may be
>>>> difficult to observe. In the absence of evidence, the statement should
>>>> be more clear that there is no evidence to the contrary -- which is not
>>>> the same as being able to claim that they *are* in fact rare.
>>> I see your point. Any suggestion on how to tweak the text?
>> It depends on what you know. AFAICT, we have no information on this
>> issue. If that's the case, then the text should just state the impact on
>> such links and say that "there is no evidence yet as to the prevalence
>> of their use".
> I'll talk to my co-authors about this one.

AOK.

Thanks,
Joe