Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

[Fernando Gont <[e-mail]>]

On 11/13/2015 08:11 PM, Lorenzo Colitti wrote:
> On Fri, Nov 13, 2015 at 1:15 PM, Fernando Gont
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>> The IP addresses and port numbers could be signaled out of band
>> using another mechanism (NFC, bluetooth, email, smoke signals,
>> well-known ports, whatever).
> 
> And for that signaling you need.... a third party.
> 
> Not for NFC, bluetooth, smoke signals, or well-known ports you
> don't. And even if you do need a third party, there's a huge
> difference between a third party that relays / snoops your traffic
> vs. a third party that just puts the two parties in touch and then
> disappears from the equation.

Could you please elaborate how this would work:

1. A is behind a diode firewall
2. B is behind a diode firewall
3. A initiates a TCP connection with B.




>> As noted, shortcuts in the current in the current architecture should
>> not be interpreted as design principles.. NATs happen to make this
>> very evident. Don't shoot the messenger for this.
> 
> And we come around to the previous argument. The situation is not
> that we are shooting NAT for coming and telling us the architecture
> is broken. The situation is that we are shooting NAT for breaking
> it.

I fully disagree. NAT can be the most evil device ever. But all this
things we've being talking about have to do with an incomplete
architecture that NAT is making evident rather than about a complete
architecture that NAT is breaking.



>> If a network has a policy of only allowing outgoing connections, then
>> any workaround to do that is an attack on that policy. And 
>> making.that workaround more difficult can thus be seen as a feature.
> 
> Such a policy is misguided

Says who? It's the policy that is being enforced. Period.


> because it ignores the reality that today 
> outgoing connections are just as dangerous as incoming ones, if not 
> more.

I disagree. Your claim can be correct for an enterprise with BYOD. BUt
it is certainly not true for virtually every home network where a number
of devices are attached to it -- possibly un-updated, with bad defaults,
etc.

In any case it's possible to DoS a device with a single packet, or
worse, that you can root a device with a single packet (see one of the
few openbsd remotely exploitable vulns, alas IPv6-based), a diode
firewall would prevent such devices from being owned from the Internet.

(Not to mention reflection attacks, etc.)

This doesn't mean "yeah.. there couldn't be nothing evil inside", but is
rather along the lines of the principle of "least privilege" applied in
security -- "if I don't need something for ding what I need to do, then
I get read of it"... whether that's superuser privileges, or
connectivity privileges.

Yes... in general, your ability to play with my network is at odds with
my network's security.


> We need a better reason to break the architecture than
> misguided policies.

The only references to architecture have been shortcomings (e.g.,
well-known ports) r not-so-clean app design such as FTP PORT -- that
become evident with NATs. The rest is policy, not architecture.

In case it's not clear: it's perfectly understandable why many of such
things happened that way. What's not understandable is that we, 40 years
later, don't learn from history and consider "design principles" things
that are not.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492