Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

[Mukund Sivaraman <[e-mail]>]

Hi Vernon

On Fri, Dec 30, 2016 at 11:45:23AM +0000, Vernon Schryver wrote:
> > From: Mukund Sivaraman <[e-mail]>
> 
> > > In 4.1.1 (IP address encoding in triggers), I suggest adding:
> > >
> > > - The encoded address prefix MUST NOT not have any extra trailing 1s
> > >   (longer address prefix than the prefix length) or the rule will be
> > >   rejected. E.g., the following trigger will be rejected:
> > >
> > >   8.1.0.0.10.rpz-client-ip
> 
> The draft tries to address that issue with these final words of 4.1.1 in
> https://tools.ietf.org/html/draft-vixie-dns-rpz-04
> 
> ]  In the case of an address block, either IPv4 or IPv6, the address
> ]  part MUST NOT contain any non-zero bits after the section indicated
> ]  by the prefix length.  For example, "8.2.0.0.10.rpz-client-ip" is not
> ]  a valid trigger, because in the address "10.0.0.2" expressed in
> ]  binary notation, a one occurs outside the first 8 bits or prefix of
> ]  the address block.
> 
> Please suggest improvements.
> 
> 
> > > Some minor nits:
> > >
> > > - Include an IPv4 example in 4.1.1 (IP address encoding in triggers)
> 
> I don't understand how that would differ from the second paragraph of 4.1.1
> which is
> 
> ]  For example, the address block 192.0.2.0/24 is encoded as
> ]  "24.0.2.0.192".
> 
> Could you suggest some more or better text?
> 
> 
> > > - Maybe include that "zz" label in v6 encoding can also appear on
> > > - either side of the address bits label sequence
> 
> I don't understand.  Describing how zz/:: works seemed difficult (as
> demonstrated by the tech.note), so the draft tries to punt to RFC 5952.
> As always, please suggest better words than are now in the draft.

It seems that I was again reading an older revision of the draft! It
appears Paul did make the changes. I'm sorry for the confusion.

> > 2. BIND makes the assumption that a trigger is exclusive within a zone.
> > So for example, if a zone transfer of an RPZ zone has taken place, and
> > currently the RPZ summary datastructures are being updated, the
> > datastructures can contain policy rules partially from an older version
> > of the zone and partially from a newer version of the zone (from the
> > transfer). As long as the change to an entire RR of a policy rule is
> > applied atomically, to BIND this is a consistent set of policy rules
> > (some of rules from previous version of zone, remaining from newer
> > version). This behavior is consistent with the RPZ rules so far, but it
> > would be wise to make a note of it.
> >
> > (Note that this behavior is different from the old BIND RPZ
> > implementation and so you may not be familiar with it.)
> 
> Are you saying that the rdataset held st->r.r_rdataset or st->r.ns_rdataset
> could be bogus in old versions of BIND?  Or that st->r.ns_rdataset and
> st->r.r_rdataset might be from differing versions of red/black trees?
> If so, that sounds like a good bug fix that might be documented in
> BIND release notes or elsewhere, but not like something that should
> be mentioned in description of the protocol.
> 
> Or do you mean that there should be words somewhere to the effect that
> RPZ results must be sane despite concurrent AXFR/IXFR activity of
> individual policy zones?  If so, please suggest some words.  Then there
> is what should happen if a transfer of a policy zone happens between
> the time QNAME rules are checked and the generally later time when
> NSIP and NSDNAME rules are checked.  The draft tries to pretend that
> all of the rules in all of the policy zones are checked instantaneously,
> and never mind real code or the delays forced by recursion.  Words
> about these issues are not BIND specific would probably be good, so
> please suggest some.

What I mean is is effectively this: an update to an RPZ zone on the
resolver may not be atomic, i.e., the resolver may not match policy
rules against a consistent before- or after- copy of the RPZ zone during
its zone transfer.

It may have a copy of RPZ policy rules in a datastructure that is
partially from a previous revision of the zone, and partially from the
incoming next revision.

Let A be the pre-transfer revision of the zone. B be the post-transfer
revision of the zone:

1. If trigger X doesn't exist in zone A and doesn't exist in zone B, the
resolver will not match against X during the transfer. This is
consistent with the case when the zone update is done atomically.

2. If trigger X exists in zone A and doesn't exist in zone B, the
resolver may or may not match against X during the transfer. This is
consistent with the case when the zone update is done atomically.

3. If trigger X doesn't exist in zone A and exists in zone B, the
resolver may or may not match against X during the transfer. This is
consistent with the case when the zone update is done atomically.

4. If trigger X exists in zone A and exists in zone B, the resolver will
match against trigger X from zone A or zone B during the transfer. This
is consistent with the case when the zone update is done atomically.

What I mean to say is that a zone transfer of policy zone is not atomic.
The resolver may match against triggers in A or B depending on the
progress of update. Only 1 trigger may match within a zone, so this can
be assumed with current RPZ syntax. But this behavior of RPZ zone
transfers not being treated atomically should be documented.

		Mukund