Re: [v6ops] FW: New Version Notification for draft-ipversion6-loopback-prefix-00.txt

[Falcon Darkstar Momot <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
On 17/02/2015 07:33, Edward Lewis wrote:
> On 2/16/15, 21:33, "Falcon Darkstar Momot" <[e-mail]
<mailto:[e-mail]>> wrote:
>
>     On 16/02/2015 19:30, Lorenzo Colitti wrote:
>>     On Tue, Feb 17, 2015 at 11:27 AM, Falcon Darkstar Momot
<[e-mail] <mailto:[e-mail]>> wrote:
>>
>>         The point is that they're addresses, not tags.  Why would you
allocate addresses that have absolutely no purpose in relation to routing?
>>
>>
>>     Pointing network  at addresses inside 127.0.0.0/8
<http://127.0.0.0/8> is a very reliable way to cause said applications
to fail fast without emitting any packets. We don't have a way to do
that in IPv6 except pointing them at ::1.
>     How about discard, 0100::/64 as per RFC6666?  This seems rather
more explicit than using loopback as discard.
>
>
> I’ve carved up this thread a bit because it contains a case of
protocol engineering vs. protocol operations conflict.
>
> Yes, architecturally, I find the use of encoding messages in addresses
rather appalling.  What I called “overt covert” channels are cute tricks
that are just that, tricks.  The more of these one tries to support in
an architecture, the more difficult it is to fully exercise innovation
in the architecture.  (My background is tied to DNS, and this is pretty
evident there.)
>
> OTOH, operationally, the Internet Protocol stack is a challenge to
manage.  The basic definition of Internet Protocols haven’t left a lot
of hooks for management and operations, having been born in the days
before there was a lot of experience upon which to draw lessons and thus
requirements.  (Again, very evident in DNS.)  Operators have over time
had to work with what they have, some of their choices present
challenges to architectural models.
>
> I’d be out of my depth to rationalize why DNSBL’s do what they do.  I
can imagine a few reasons (or excuses depending on one’s perspective)
and I am tempted to add some conjecture.  But that would be wrong on the
list.
>
> For controlled interruption, the uphill battle was passively coercing
the installed base to be caught in the trap (as systems errantly sending
unintended queries).  The way to do this is to tap into the address
record lookups.  The backchannel is the operations use of logs - where
the ‘connection to 127.0.53.53 failed’ would appear.  Controlled
interruption includes other record types, including a TXT record which
has a short message.
>
> The goal is two fold.  One is to get a message back.  Two is to have
the node not leak anymore than it already has.  (IMHO, the idea of
wanting a loopback is a bit overreaching, the goal is not to have the
node successfully send anything within itself.)
>
> Way back (1998+/-) when DNSSEC was being developed, I wanted to ‘get a
message back’ and thought I’d be able to depend on SNMP - a nice
architectural thing to, but that wasn’t achievable.  (There’s no real
good back channel for DNSSEC detection of failures - it’s still actively
discussed on mailing lists.)  That’s just an example of the challenge of
getting ‘a message back.’  (The analogy here is a bit weak, DNSSEC
wanted to reach the administrator of the node with the failure, for
controlled interruption and DNSBL’s have different relationships.)
>
> The suggestion to use the discard block is an interesting one, but it
doesn’t quite attain the goal of preventing leakage.  The goal is to
have the node not even generate the datagram, as opposed to having a
recipient know to discard it.  It’s not a bad suggestion, but the mere
fact the action is taken at the recipient means there’s that much
leakage.  (Of course, I don’t know what existing implementations would
do with the address block I’ll propose to mean ‘don’t even make this
datagram’.)
>

While it is possible to envision a DNSBL being queried for relay
addresses to use internally to a host as part of mail routing, what I
understand is that the DNSBL is not necessarily dispositive (in
spamassassin it certainly isn't), and so the MTA or its spam filter
makes the query but processes the returned A record as a tag in nearly
every case.  Certainly, using a DNSBL to get a next hop is operationally
disadvantageous if the DNSBL is not working correctly, and could even be
used to man-in-the-middle mails.

So, while someone might be using DNSBL queries to route mail, it doesn't
seem like either the normal or correct thing to do.  It would be
interesting to hear from a DNSBL operator on this topic, if for no other
reason than to ask why they do as they do with 127.0.0.0/8 addresses.

This quandary is not illuminated in RFC5782, the DNSBL RFC.  However, we
do there specify (perhaps inelegantly) in section 2.4 that DNSBLs are to
return A records for queries against IPv6 addresses just as they would
for IPv4.  The TXT record is used only for a comment (perhaps this is
why it is not used as a tag).  Why a new RRtype is not requested I could
not say.

On a different topic, I may have misspoke when recommending ipv6 discard
for this purpose - since it is intended for RTBH, it doesn't prevent
leakage at all (quite the opposite).  Nor does link-local, since the
traffic may be leaked across a link.  The documentation prefix would,
but it is not appropriate to apply non-documentation semantics to
documentation addresses.

Loopback does not prevent leakage.  A local listener could still receive
the traffic, and that local process may be running with whatever
credentials.  It is as weak for this purpose as link-local.

::/128 would definitely prevent leakage.  This is only one address, and
it does have the meaning "unspecified" if memory serves, which seems
exactly what one might want if they would rather the packet not even be
generated.

If someone needs a set of addresses, we'd need to assign a prefix
(perhaps 100:1::/64?) for that, since nothing else fills that role, but
it's difficult to find a use case that isn't architecturally abhorrent. 
Then again, if that is what it takes to prevent people from using other
things (such as loopback) for this purpose, that's exactly what we
should do.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
 
iQIcBAEBAgAGBQJU493GAAoJEM2g2ken2JPs5pEQAJdze1aEKvdPJC95lCYAZfZl
24uvM/6aAsX86A14vmPR59OIhH6d8B+732QSOBGrITfEDGMRrcMHDNUXaPqK0S3O
GnbbHnaHB+dy4ZI/am24SFnBGpj55Vw+NmB2akVmpIJQcYuP5aMCURWpSVv3ogny
78zutlmXODGcZ785YKkebs86uTMWK0AE12Gil/PCJNAKG8lbx///+RO1SZOX9+wS
nzkrnHBpvOy3rk56ppBa9xWBnnoWMj/qMmFxTRT1Z75VAWgO489QECSOI8uSJ7JO
MndJ4Dq4dVTyeEBD+ppHmMfHj4Sv9NlWoodxmPphjEWhDjxCYQMan2OuF/Gt1LEd
YEdDRPeAd945XHfcb/UZCfIJp+e8+zBEGr3l5qd25knIVY9G1eCAS9DrSixdVqO/
RL9L3nqzMFlTBAwcObHDh4hEafk/lroD+vdV8pEeOTFjUlqlQp2gAteSKisspYIQ
uEJvNsVaPnuQFxw0mtOQ5qii8R6/qRWCQri7MPnHLL09cNE+CMxHvYn8puq7C9XE
XMAfkrR6oPPqxUt0DqjAMu3A1bNzPNgB9bjbaE6bJGwG39jnUovET/vzyaFV6Z4G
wOXs/6oWJcvX3XXPHMPiXR/PqCaYPqukNV5ygyIrjphRNEx4SUyXGwoK2JQzC1xb
Sv7FcDFH9flG1tTb9VGc
=Nqlh
-----END PGP SIGNATURE-----