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. Joe > On Nov 25, 2018, at 4:59 AM, Nick Hilliard <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tsv-art _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
