questions about SILC's IP and DNS requirements [was: Re: Implement ExternalIp config directive]

On Wed 2008-09-24 11:28:06 -0400, Pekka Riikonen wrote:

> It tries to bind to the ip defined in the primary (which can be
> 0.0.0.0 if public_ip is used) and the public_ip is used to create
> the server ID.

Can i ask why the IP matching is important in the first place?
sections 4.1 and 4.2 of the I-D [0] suggest that valid public IP
addresses and DNS are *requirements* of the protocol:

   When client connects to server the server MUST perform IP address
   lookup and reverse IP address lookup to assure that the origin host
   really is who it claims to be.  Client, a host, connecting to
   server SHOULD have both valid IP address and fully qualified domain
   name (FQDN).

[...]

   This section describes the procedure when server connects to its
   router (or when router connects to other router, the cases are
   equivalent).  The procedure is very much alike to when a client
   connects to the server thus it is not repeated here.

Why are these things required, given that silc is supposed to give us
the ability to properly authenticate using more reliable frameworks?
Requiring DNS and IP validity (not to mention reverse DNS) makes silc
substantially dependent on specific lower-level protocols (what about
IPv6?  What about AAAA records?  What about running silc over
UNIX-domain sockets on a multi-user system, or through tunnelled
transports, etc?) and brittle in the face of real-world constraints
(no silc servers can realistically run from dynamic IP addresses?  No
silc servers on IPs where you don't have reverse DNS permissions?)

If these were phrased in the draft as SHOULDs, that would open the
door for alternate implementations at least.  As it stands, it seems
that they limit the utility of SILC in a number of circumstances that
seem likely to become more common in the future.  Removing the
requirements entirely would make it clear that the real reassurances
for authenticity come from the crypto layer, and not the other layers,
right?  Isn't the point of the protocol to protect against cleartext
tampering?  Why should an attacker who is only able to poison my DNS
PTR lookups be able to make my client fail to connect to a silc
server?  Are there good reasons to enforce IP and DNS rules that i'm
not aware of?

    --dkg

[0] http://tools.ietf.org/rfcmarkup?doc=draft-riikonen-silc-spec#section-4.1

_______________________________________________________________________
Info:    https://lists.silcnet.org/mailman/listinfo/silc-announce
Archive: https://lists.silcnet.org/pipermail/silc-announce
FAQ:     http://silcnet.org/support/faq/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIVAwUBSNp0kszS7ZTSFznpAQLJSw//ShMtCfXfBUAtsK6toMH0I8DGP5+iSuBb
uDSkT5K2xEu2IYicfG+3qYhWoBIqH4dU5yufGmNmUojntStcyNEWlgdCU1xG8IlG
Ejjnne64MspuPqhp+J/YHnbep1NnLHR4LBdhok8EnIQDNDj4e3l8ZVnLzmy8KPM3
vxlk7/y8eriSDOmsc0psl7UVJOx9jXydOtkOBnjKaG4e30MGeBgdycDODaQwN1kX
XZS2whgrQBrTZcdSRm+JfviBzE4pI0khdNqcl8O1W50BmyGtS0MJ6koIklNPiTDB
1sGSJH3vwB0D4JrwV807ZCZjtokTvNqAS94rUZe+KBP1T6hgZP+O0newUvW87gL1
eHa7S1y8M0GQUyhzCEf+t9exCPe6hokBy8wtdYq16CEHPGerKIWO7Tww0D1H0yP9
B3vwGb64ta6KmevCLdLTxXUaesfvA3uSV58axT+yl+YNzLc7YciZoNK4OUsQ9Gx7
DR46QtcPBgmjHnLK1GKJJHIQkM8gHFIADmI7pBZTCSy8YN7HsVOk4/1djMCHo6MO
NUA2CdkGrqQWqxZ3j6oiYMyYqqaf9+MRv3WmsJBP9nlrpLayo4OqFZpZDZcg5sUR
2asfrSaCx0elZEO12JCnB80n0muNro2XazP8GchEaP8klr5OiNNpZnqSPr4bPgPl
jwamHgdqyuo=
=uevK
-----END PGP SIGNATURE-----