On 2018-11-26 04:53, Joe Touch wrote:
> A reasoned discussion of the pros and cons would be useful.
>
> What we have is the perspective, often heavily represented by vendors and operators, of the driving reality that:
>
> a) implementing extended features is an attack on profits
> b) properly configuring and monitoring extended features is an attack on effort
>
> A reasoned argument would be useful. That is not what has been repeatedly presented, IMO.
I don't think that's entirely fair to RFC7045. But the fact is that
there's a tussle here between the desire for the ability to deploy
new protocols freely, and the desire for the ability to block
potentially harmful or malicious traffic. The definition of "harmful
or malicious" is not universally agreed. "Harmful to my business model"
is certainly one possible interpretation. But then, we decided to
implement the Internet as a largely unregulated competitive system,
so we got tussles.
As far as I can tell, there is nothing much that the IETF can do about
this.
Brian
>
> Joe
>
>> On Nov 25, 2018, at 4:59 AM, Nick Hilliard <nick@xxxxxxxxxx> wrote:
>>
>> Joe Touch wrote on 25/11/2018 06:24:
>>> The reality is that standards are not followed, agreed. That does not
>>> imply that we need to relax those standards - instead, it can be
>>> reason to fix broken devices.
>>> Working at the level of the most broken device is no way to run a
>>> production Internet.
>>> And claiming that doing so is appropriate for security reasons is
>>> just as broken, as it always has been.
>> Joe,
>>
>> another point of view would be that operator feedback should be welcomed because sometimes protocols are found to be difficult to implement fully, or when implemented fully cause unforeseen consequences. EHs are a good example of this. When originally conceived - for the best of intentions - the spec was sufficiently loose that they were not just unimplementable from a practical point of view, but the spec was open to protocol level security problems. RFC7112 describes some issues relating to EHs, but there are plenty of other examples.
>>
>> How, where and when to filter EH packets creates a bind, no doubt about it. Some EHs are intrinsically troublesome (e.g. anything with hbh processing requirements); others can be processed without issues. The IETF can choose to ignore this problem or get involved and have some influence about what might constitute best practice. If this happens, vendors might even fix some of their silicon. Declaring that the problem exists only on one side won't make the Internet better.
>>
>> Nick
>>
>> _______________________________________________
>> Tsv-art mailing list
>> Tsv-art@xxxxxxxx
>> https://www.ietf.org/mailman/listinfo/tsv-art
>
>
