Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery

[Alan DeKok <[e-mail]>]

Stefan Winter wrote:
> My point so far is: loops can occur, so we should do all we can to
> detect and prevent them. This requires all NAPTR -> SRV -> A/AAAA
> lookups to be done, and look for inconsistencies in the resulting set.
> 
> Brian's counter-point is: loops can happen also outside dynamic
> discovery, too; and will fix themselves by busting RADIUS packet
> boundaries. In the interest of speed, let's be less thorough in finding
> them and take shortcuts in DNS response evaluation wherever possible.

  Sounds good to me.

  Some notes on Brian's text:

> In FreeRADIUS the duplicate detection relies on the authentication vector and
> size of the packet as well as the src/dst ip/port.  This would cut short most
> naturally occurring loops after a finite number of iterations 

  It won't.  The duplicate detection is the RFC 5080 mechanism.  It
detects a NAS retransmitting the identical packet.  It doesn't affect
(or help with) loop detection.

>  -- the exception being
> scenarios where hops modify transiting requests in a way that is not
> eventually idempotent,

  All proxies modify the RADIUS packet.  The ID field changes (usually),
and the shared secret is different, so the authentication vector field
changes, too.

> without also creating a packet that exceeds any
> RADIUS packet format limitations, or implementations that change their source
> ports frequently.  RADIUS administrators should be advised not to disable
> duplicate checking on incoming TCP connections when DDDS is in use.

  I think this advice is wrong.  RFC 6613 Section 2.6.1 forbids
retransmission of duplicate packets over TCP.  So any packet in a loop
will look different the second time around.  Or if it's the same, then
it MUST NOT be transmitted the second time, and the loop is broken.

> General loop detection in RADIUS is an issue beyond the scope of the draft --
> albeit one which does deserve some attention.

  That's very true.

> While it is a helpful safeguard to prevent a server from trying to connect
> to itself, the scenarios sketched out above are likely to be rare enough that
> a balance needs to be struck between the performance of the normal, functional,
> case and the efficacy of safeguards, which cannot be perfect as DDDS cannot
> in and of itself solve the problem.  Given the expense of performing a full
> enumeration of the DDDS tree, I suggest that line should be drawn somewhat
> short of that measure. with implementations given the option to be more
> thorough where they deem fit.  I'd suggest that servers SHOULD lookup and
> loop-guard all A/AAAA records for RRs of an active SRV priority, with a hard
> failure if even one matches, and SHOULD likewise loop-guard against all
> A/AAAA addresses retrieved when multiple A/AAAA RRs respond to the same
> owner, and of course MUST never try to forward to the same listening address
> upon which the original request was received.

  That analysis presumes the *outgoing* address of the server is the
same as it's *incoming* address.  Which doesn't have to be the case.

  It may be worth updating the draft to suggest that servers using
dynamic discovery either:

  (1) use the same address for incoming and outgoing packets

  (2) publish a different DNS record indicating their outgoing address

  The SMTP world has had similar issues for a long time.  Solutions like
SPF may be applicable here.

> I might further offer that implementations MAY shut down all attempts to connect
> to a realm if they ever are asked to connect to themselves for that realm in a
> manner that generates noisy complaints in logs and requires manual intervention
> to clear.

  I agree.  This also brings up issues of authenticating the DNS
records.  It may be useful to have reverse IP records, which serve as a
cross-check.

  e.g.  if looking up "example.net" gets you 192.12.6.10, then doing a
reverse IP lookup on that IP should get you "example.com" (among others).

  The document doesn't discuss reverse IP records or lookups.

>  In general these problems are of the type that will not self-heal and/or
> they indicate a security incident which merits notification of an administrator.
> Most implementations will probably elect not to permanently poison a realm for
> fear that a single spoofed DNS result could use this as a DoS.  They should be
> at least encouraged to log such episodes as security events.

  Having a reverse IP lookup can help with this situation.  If the
forward and reverse records don't match, then that can be discovered
automatically.  And before the proxy starts a secure connection to the
home server.

  Alan DeKok.