On 30/08/2016 10:14, Joe Touch wrote:
> 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.
2460bis has pointers in such cases (and should include a pointer
to deprecate-atomfrag when it becomes an RFC). I don't think it is
helpful to readers of 2460bis to burden it with all the rationales.
> 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.
I don't think 2460bis will be the end of history, any more than 791 was
the end of IPv4 history. Incremental change will continue.
Regards
Brian
>
>
>>
>>
>>
>>
>>
>>>>> 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
>
>