Re: Results of IETF-conflict review for draft-williams-exp-tcp-host-id-opt-07

[Fernando Gont <[e-mail]>]

On 01/27/2016 07:10 AM, Harald Alvestrand wrote:
> This one surprised me a bit.
> 
> Asking for blockage of an ind-sub is a fairly unusual thing.
> I kind of expected to find in the IESG review would explain the nature
> of the conflict, but the totality of the review is:
> 
> "The IESG has concluded that this document violates IETF procedures about
> pervasive monitoring (RFC 7258) and should therefore not be published
> without IETF review and IESG approval. This work is related to IETF work
> done in the INTAREA WG."
> 
> The procedures I could find described in RFC 7258 are these:
> 
>    Those developing IETF specifications need to be able to describe how
>    they have considered PM, and, if the attack is relevant to the work
>    to be published, be able to justify related design decisions.  This
>    does not mean a new "pervasive monitoring considerations" section is
>    needed in IETF documentation.  It means that, if asked, there needs
>    to be a good answer to the question "Is pervasive monitoring relevant
>    to this work and if so, how has it been considered?"
> 
>    In particular, architectural decisions, including which existing
>    technology is reused, may significantly impact the vulnerability of a
>    protocol to PM.  Those developing IETF specifications therefore need
>    to consider mitigating PM when making architectural decisions.
>    Getting adequate, early review of architectural decisions including
>    whether appropriate mitigation of PM can be made is important.
>    Revisiting these architectural decisions late in the process is very
>    costly.
> 
> The draft in question does have a "Pervasive Monitoring Considerations",
> so the issue has certainly been considered by the authors. One may agree
> or disagree with their conclusions, but one can't argue that they didn't
> consider it.

I agree with Harald.

Besides, if this proposal is knocked down for including a host_id option
(which, skimming through the I-D doesn't seem to be some global
identifier) in flows that traverse a nat, then I wonder:

   What would be the take on deploying IPv6 on such network, since that
   would obviously reveal host identity even more than a host_id option?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492