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

[Stefan Winter <[e-mail]>]

Hi,

>> 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.

I'd feel good about the more relaxed attitude if there *were* a loop
detection that works reliably, and independent of the discovery
mechanism (DDDS vs. config file).

I'd like to bring up the topic of a dedicated "TTL" attribute in Berlin
(again, as I've previously received some beating for proposing it).

I think this time the underlying situation has changed: Sam's proposal
to lift the packet size boundary on TCP/TLS links means
eternally-proxies packets now can bounce a LOT longer between hops until
their aggregated Proxy-State size busts the packet limits. Relying on
that sort of phenomenon becomes less and less useful IMHO.

>> 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.

Good :-) It would be very simple and straightforward to write an I-D
registering an integer attribute "Packet-TTL", with an integer value
that is to be decremented.

>   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.

Yet another new DNS record would add much complexity to the draft; for
little benefit. The TTL would solve this in one go.

It would be equivalent to the SMTP's "Too many Received headers:
suspecting a loop", much more than SPF.

>   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.

It doesn't, because the authentication of the results learned is done by
X.509 certificate inspection during connection time. I find that a much
more reliable mechanism than reverse IP checks. (if an attacker can fake
an A record, then it may also be able to fake a PTR record).

>>  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.

Having it attempt /one/ TLS connection to the target doesn't consume
much computing power. The discovering server could also keep a list of
servers it has recently tried and found unacceptable; and save itself
the effort of trying over and over again.

This could be mentioned in Security Considerations, if you find it
useful/important to have?

Greetings,

Stefan Winter

> 
>   Alan DeKok.
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext
> 


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]