Op 15-12-2020 om 09:10 schreef Erik Kline via Datatracker:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> [ questions ]]
>
> [ section 3 ]
>
> * I assume it's not a big deal that sometimes the client cannot easily
> tell when its upstream IP address has changed (vis. RFC 7873 S6
> considerations)?
>
> NAT makes it difficult to comply with the MUST for clients stated
> in section 8, but...what should a client do if only has, say, an
> RFC 1918 address and is quite likely to be behind a NAT? If its
> server is also a likely-NAT'd IP then it might presume no NAT between
> the two, but if the server has a global IP address...I suppose it
> can just rotate the per-server cookies once per year?
Thanks Erik,
Indeed, I have added a paragraph to the Security Considerations that
preventing tracking of the public IP of a routing device that performs
NAT is beyond the scope of this document, see:
https://github.com/NLnetLabs/draft-sury-toorop-dns-cookies-algorithms/pull/23/commits/83155e4bfed1afb08611723a13f9ebc045179e63
The nits have been processed too.
Cheers,
-- Willem
> [[ nits ]]
>
> [ section 1 ]
>
> * Final sentence of the final paragraph:
> "in a Client protecting fashion" ->
> "in a privacy protecting fashion"? (to match the abstract)
>
> [ section 8 ]
>
> * "five minute" -> "five minutes"
>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
