Re: Update on RFC7871 - Client Subnet in DNS Support

[David Neuman]

+1, excited to see this one come through.

On Fri, Jun 2, 2017 at 12:15 PM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> We are planning to add support for RFC7871 to Traffic Router. Here is a
> brief description of the feature. Comments appreciated!
>
> Background
>  Clients do not make DNS requests directly to TR. Typically TR requests
> come from DNS resolvers within the infrastructure. Today, Cache Group
> selection for DNS Delivery Services is based on the IP address of the DNS
> resolver making the request to TR. RFC7871 includes the client subnet in an
> EDNS0 option within the DNS query. When the ECS OPT is present (and the
> feature is enabled via a TR parameter), Traffic Router will use this IP in
> place of the source IP of the DNS packet (the IP of the resolver). This IP
> will be used in the CZF and maxmind lookups.
>
> Requirements
>
>   1.  If DNS query includes ECS option in the Optional Record, Traffic
> Router will use the IP address included in the ECS option as the client
> address for Cache Group Selection
>   2.  If there are multiple ECS options in the Optional Record, the one
> with the longest IP prefix - i.e. the ECS option with largest Source Net
> Mask will be used
>   3.  If DNS query includes ECS Option, then DNS response from Traffic
> Router will also include the ECS Option. In the response the Scope Net Mask
> is set to be same as the Source Net Mask. This is required by RFC 7871 for
> DNS caching to work properly.
>   4.  It is assumed that customers/operators will ensure that Source Net
> Mask for a subnet specified in the ECS is at greater than or equal to the
> net mask for the corresponding subnet entry in the CZF file. e.g. if ECS
> Option has 192.168.10.0/8, then 192.168.0.0/16 in CZF will work, but
> 192.168.10./28 will not work.
>   5.  Add a TR parameter to disable use of ECS field even when present
>
> Design
>
> To support this feature new logic will be added to NameServer.query()
> function. The new logic will be responsible for parsing ECS option in the
> OptionalRecord of the incoming DNS Request, and retrieving the Client IP
> address and the associated Source Net Mask (Scope Net Mask must be 0 in the
> incoming Request per RFC 7871). Please note that the underlying DNS library
> xbill/dnsjava already has support for parsing the ECS Options. These
> functions from the library will be leveraged.
>
>   1.  Message.getOPT().getOptions(EDNSOption.Code.CLIENT_SUBNET) will
> return list of ClientSubnetOption for the incoming Request (Message)
>   2.  ClientSubnetOption has public methods to retrieve netmask and Client
> IP address:  getSourceNetmask(), getAddress()
>
> If ECS option is present, then the IP address retrieved from the ECS
> option, and will be passed as the Client IP address to the Traffic Router
> (through getZone call) for CZF/geo lookup
>
> If ECS option is present, then ClientSubnetOption will be created and
> included in the DNS response. In the Response the Scope Net Mask of the
> ClientSubnetOption is set as the Source Net Mask
>
> Testing
>   We’ll test against all of the various CZF, National, Regional, VPN
> Blocking features and will do our best to check with DNSSEC
>
> —Eric
>
>
>
>
>
>

Update on RFC7871 - Client Subnet in DNS Support

[Eric Friedrich (efriedri)]

We are planning to add support for RFC7871 to Traffic Router. Here is a brief 
description of the feature. Comments appreciated!

Background
 Clients do not make DNS requests directly to TR. Typically TR requests come 
from DNS resolvers within the infrastructure. Today, Cache Group selection for 
DNS Delivery Services is based on the IP address of the DNS resolver making the 
request to TR. RFC7871 includes the client subnet in an EDNS0 option within the 
DNS query. When the ECS OPT is present (and the feature is enabled via a TR 
parameter), Traffic Router will use this IP in place of the source IP of the 
DNS packet (the IP of the resolver). This IP will be used in the CZF and 
maxmind lookups.

Requirements

  1.  If DNS query includes ECS option in the Optional Record, Traffic Router 
will use the IP address included in the ECS option as the client address for 
Cache Group Selection
  2.  If there are multiple ECS options in the Optional Record, the one with 
the longest IP prefix - i.e. the ECS option with largest Source Net Mask will 
be used
  3.  If DNS query includes ECS Option, then DNS response from Traffic Router 
will also include the ECS Option. In the response the Scope Net Mask is set to 
be same as the Source Net Mask. This is required by RFC 7871 for DNS caching to 
work properly.
  4.  It is assumed that customers/operators will ensure that Source Net Mask 
for a subnet specified in the ECS is at greater than or equal to the net mask 
for the corresponding subnet entry in the CZF file. e.g. if ECS Option has 
192.168.10.0/8, then 192.168.0.0/16 in CZF will work, but 192.168.10./28 will 
not work.
  5.  Add a TR parameter to disable use of ECS field even when present

Design

To support this feature new logic will be added to NameServer.query() function. 
The new logic will be responsible for parsing ECS option in the OptionalRecord 
of the incoming DNS Request, and retrieving the Client IP address and the 
associated Source Net Mask (Scope Net Mask must be 0 in the incoming Request 
per RFC 7871). Please note that the underlying DNS library xbill/dnsjava 
already has support for parsing the ECS Options. These functions from the 
library will be leveraged.

  1.  Message.getOPT().getOptions(EDNSOption.Code.CLIENT_SUBNET) will return 
list of ClientSubnetOption for the incoming Request (Message)
  2.  ClientSubnetOption has public methods to retrieve netmask and Client IP 
address:  getSourceNetmask(), getAddress()

If ECS option is present, then the IP address retrieved from the ECS option, 
and will be passed as the Client IP address to the Traffic Router (through 
getZone call) for CZF/geo lookup

If ECS option is present, then ClientSubnetOption will be created and included 
in the DNS response. In the Response the Scope Net Mask of the 
ClientSubnetOption is set as the Source Net Mask

Testing
  We’ll test against all of the various CZF, National, Regional, VPN Blocking 
features and will do our best to check with DNSSEC

—Eric

Re: [VOTE] Release Apache Traffic Control 2.0.0-incubating (RC2)

[Dave Neuman]

Unfortunately I have to be -1 due to
https://issues.apache.org/jira/browse/TC-365.
The source tar ball does not extract a proper directory structure.

Thanks,
Dave

On Thu, Jun 1, 2017 at 9:31 AM, Jeff Elsloo  wrote:

> I'm +1 on this. Thanks for creating the RC Eric!
> --
> Thanks,
> Jeff
>
>
> On Thu, Jun 1, 2017 at 9:30 AM, Eric Friedrich (efriedri)
>  wrote:
> > Hello All,
> >
> > I've prepared the next candidate release for incubator-trafficcontrol
> v2.0.0 (RC2)
> >
> > Changes since 1.8.0:
> > https://github.com/apache/incubator-trafficcontrol/
> compare/RELEASE-1.8.1-RC0...RELEASE-2.0.0-RC2
> >
> > This corresponds to git:
> >  Hash: 795ea3adf2003dd27523b6b9ff4691f23d41ce30
> >  Tag: RELEASE-2.0.0-RC2
> >
> > Which can be verified with the following:git tag -v RELEASE-2.0.0-RC2
> >
> > My code signing key is available here:
> > http://pgp.mit.edu/pks/lookup?op=get=0xF2200BAB9AB7BDD5
> >
> > and here:
> > https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS
> >
> > Make sure you refresh from a key server to get all relevant signatures.
> >
> > The source .tar.gz file, pgp signature (.asc signed with my key from
> > above), and md5 and sha512 checksums are provided here:
> > https://dist.apache.org/repos/dist/dev/incubator/
> trafficcontrol/2.0.0/RC2
> >
> >
> > The vote will remain open until Tuesday, June 6, 2017.
> >
> > Thanks!
> > Eric Friedrich
> >
>

Re: LDAP Access

[Mark Torluemke]

I do not support the position of what appears to be dramatically changing
access without a tangible migration plan -- I feel like we should comply
with the "principle of least surprise" in this case.



On Fri, Jun 2, 2017 at 8:28 AM, Jeremy Mitchell 
wrote:

> I'm fine merging Rob's PR -
> https://github.com/apache/incubator-trafficcontrol/pull/627
>
> as long as it's understood that pure LDAP users (users with no user in the
> tm_user table) will not work for 99% of the UI or the API.
>
> If they want to get back that 99%, they need to have a user created for
> them in the tm_user table where username=their ldap username...
>
> jeremy
>
>
> On Thu, Jun 1, 2017 at 12:20 PM, Dave Neuman  wrote:
>
> > Just because we *can* do something doesn't mean we *should* do something.
> > I don't think we should try to over engineer this part of the system and
> > make it any more complicated than it needs to be.
> > I think Rob's PR should be merged so that LDAP users, by default, have
> very
> > limited capabilities.
> >
> > On Thu, Jun 1, 2017 at 10:16 AM, Robert Butts 
> > wrote:
> >
> > > > that ship has sailed when the roles/capabilities model was agreed
> upon
> > >
> > > I don't agree. We could configure PostgreSQL Roles and Row Security
> > > Policies with the same capabilities, and the same UI. Users would click
> > the
> > > "create role" or "assign capability" button, and the UI would issue an
> > API
> > > call which issues a SQL command to create or assign the appropriate
> > > PostgreSQL Roles and Policies. Same model, different backend.
> > >
> > > On Thu, Jun 1, 2017 at 10:09 AM, Jeremy Mitchell <
> mitchell...@gmail.com>
> > > wrote:
> > >
> > > > > @mitchell852 Actual PostgreSQL users. So, Traffic Ops users would
> > _be_
> > > > PostgreSQL users. There wouldn't be a single "trafficops" Postgres
> > user,
> > > > every TO user would have their own user in Postgres itself.
> > > >
> > > > ^^ Sounds like we need a Postgres DBA for that :) Plus, I think that
> > ship
> > > > has sailed when the roles/capabilities model was agreed upon and is
> > > > currently in the works...
> > > >
> > > > Just to clarify for others, currently, when you login via LDAP and no
> > > user
> > > > is found in the tm_user table with the same username, we assign the
> > > > "read-only" role to the "current user". Rob doesn't think (and he's
> > > > probably right) that the "read-only" role is restrictive enough for
> > these
> > > > LDAP only users. There are lots of GET routes that "read-only" users
> > can
> > > > access that contain "sensitive" info... (depending on your definition
> > of
> > > > sensitive)
> > > >
> > > > Anyhow, with this PR -
> > > > https://github.com/apache/incubator-trafficcontrol/pull/544 - the
> > > concept
> > > > of "capabilities" was introducedroles can now have
> > capabilitiesso
> > > > in theory we could create a role called "Graph Viewer" or something
> > which
> > > > maps to the cdn-graph-read capability that maps to certain api
> > > > endpoints...and then the "Graph Viewer" role would be automatically
> > > > assigned to LDAP only users..just an example.
> > > >
> > > > ^^ however the role/capabilities thing only applies to the API (not
> the
> > > > current TO UI) and was to be enforced by the API gateway
> > > >
> > > > In my opinion, trying to do what's best for the TO UI and the TO API
> at
> > > the
> > > > same time is very difficult, thus, my push to deprecate the TO UI and
> > the
> > > > entire UI namespace of endpoints, in favor of the TO API and the API
> > > > namespace... TO API + API Gateway + Roles/Capabilities gives us more
> > > > granularity
> > > >
> > > > Jeremy
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Jun 1, 2017 at 9:39 AM, Jeff Elsloo 
> wrote:
> > > >
> > > > > We use LDAP all the time. It's optional of course, but in our
> > > > > deployment nobody should be using local accounts unless they're not
> > in
> > > > > LDAP for some reason (external users, portal users, etc).
> > > > > Application/API accounts could go either way, but users of the TO
> UI
> > > > > should use LDAP whenever possible to avoid having to manage
> multiple
> > > > > accounts/passwords.
> > > > >
> > > > > Basic enterprise operations best practices dictate centralized user
> > > > > management, and most enterprises do so using some sort of LDAP
> based
> > > > > directory (Active Directory, OpenLDAP, etc). I'm a hard -1 on
> moving
> > > > > away from this model. If anything we need to make our LDAP
> > > > > implementation more flexible.
> > > > > --
> > > > > Thanks,
> > > > > Jeff
> > > > >
> > > > >
> > > > > On Thu, Jun 1, 2017 at 9:10 AM, Dewayne Richardson <
> > dewr...@gmail.com>
> > > > > wrote:
> > > > > > I have a question in a similar vein, how often do we really use
> > LDAP?
> > > > My
> > > > > > understanding is we created LDAP access to allow external users
> in