All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Clark <sclark46@earthlink.net>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Jan Engelhardt <jengelh@medozas.de>,
	David Miller <davem@davemloft.net>,
	pascal.mail@plouf.fr.eu.org, netfilter-devel@vger.kernel.org
Subject: Re: rules matching ipv6 prefix addrs
Date: Thu, 04 Nov 2010 07:08:19 -0400	[thread overview]
Message-ID: <4CD29423.6050009@earthlink.net> (raw)
In-Reply-To: <4CD21679.2070508@zytor.com>

On 11/03/2010 10:12 PM, H. Peter Anvin wrote:
> On 11/03/2010 06:52 PM, Jan Engelhardt wrote:
>>
>> I take it you mean a setup where addresses are automatically assigned
>> (DHCPv6, PPP).
>>
>
> DHCPv6, PPP, RA, anything.  Keep in mind that "expect prefix changes" 
> is a deliberate part of the IPv6 systems design.
>
>> Still I don't see the problem - any security-conscious person would use
>> a drop-by-default ruleset. So a change of prefix address would, if
>> anything, cause packets to get dropped in FORWARD. (What do we have the
>> "ip6table_filter.forward" module option for? Right. And why is it set to
>> ACCEPT by default? *headshakethere*)
> >
>>> In IPv4 this is generally masked by NAT, but in IPv6 it affects every
>>> host.
>>
>> Different scenario. Because packets from Internet are
>> only destined for your home gateway address, they would get locally
>> delivered in the normal case, and any forwarding is an opt-in
>> process on the admin's behalf.
> >
>> If you used a FORWARD-DROP policy in IPv6, forwarding also becomes the
>> same opt-in process. So it's not like NAT would be any magic.
>> On Wednesday 2010-11-03 23:36, H. Peter Anvin wrote:
>
> Sorry this is nonsense.  There is a huge difference -- with IPv6, the 
> local prefix affect the addresses *on your internal network*, whereas 
> with IPv4/NAT, they do not.  In theory, IPv4 with dynamically assigned 
> publically routable blocks would have the same problem, but in 
> practice those simply do not exist.
>
> Consider for example the case where I get from my ISP the netblock 
> 2001:0db8:ac10::/48.  I subnet this internally with subnet numbers 
> prefixed by /52 security domains, i.e 2001:0db8:ac10:0000::/52, 
> 2001:0db8:ac10:1000::/52 and so forth.  Accordingly, my ip6tables 
> would contain rules as to what kind of traffic can flow between these 
> prefixes.
>
> Now, the upstream (ISP-assigned) prefix changes to 
> 2001:6b2f:1705::/48.  RA will handle reassigning addresses to actual 
> downstream hosts, but things that explicitly encode IPv6 addresses 
> need to be changed, and that includes ip6tables, in this case these 
> rules now need to refer to 2001:6b2f:1705:0000::/52, 
> 2001:62bf:1705:1000::/52 and so on.
>
Won't this break existing tcp connections if all of a sudden you get a 
new address?

>> Different scenario. Because packets from Internet are
>> only destined for your home gateway address, they would get locally
>> delivered in the normal case, and any forwarding is an opt-in
>> process on the admin's behalf.
>>
>> If you used a FORWARD-DROP policy in IPv6, forwarding also becomes the
>> same opt-in process. So it's not like NAT would be any magic.
>
> You're assuming (a) that I'm talking about a home gateway here (which 
> may be, but is far from certain -- the dynamic prefixes are a design 
> feature of the entire IPv6 Internet, and any entity that is not large 
> enough to have direct access to BGP6 is required to handle arbitrary 
> prefix changes), and (b) that I'm only concerned about entry/egress 
> control, but this also affects internal control.
>
>     -hpa
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)




  parent reply	other threads:[~2010-11-04 11:08 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-02 20:52 rules matching ipv6 prefix addrs David Miller
2010-11-02 21:24 ` Maciej Żenczykowski
2010-11-03  7:37 ` Patrick McHardy
2010-11-03  9:29 ` Pascal Hambourg
2010-11-03 10:51   ` Jan Engelhardt
2010-11-03 12:19   ` David Miller
2010-11-03 12:32     ` Jan Engelhardt
2010-11-03 21:55       ` David Miller
2010-11-03 22:36         ` H. Peter Anvin
2010-11-03 22:52           ` Jan Engelhardt
2010-11-04  2:12             ` H. Peter Anvin
2010-11-04  4:14               ` Patrick McHardy
2010-11-04  8:58               ` Jan Engelhardt
2010-11-04 11:36                 ` H. Peter Anvin
2010-11-04 11:53                   ` Jan Engelhardt
2010-11-04 14:41                     ` H. Peter Anvin
2010-11-04 20:02                       ` Pascal Hambourg
2010-11-04 12:07                   ` Pascal Hambourg
2010-11-04 11:08               ` Stephen Clark [this message]
2010-11-04 11:29                 ` Pascal Hambourg
2010-11-04 12:07                   ` Stephen Clark
2010-11-04 12:19                     ` Pascal Hambourg
2010-11-04 13:34                 ` Jozsef Kadlecsik
2010-11-04 14:41                 ` H. Peter Anvin
2010-11-04 17:35                   ` Jeff Haran
2010-11-04 18:45                     ` H. Peter Anvin
2010-11-04 19:24                   ` Jan Engelhardt
2010-11-04 19:26                     ` H. Peter Anvin
2010-11-04 11:55               ` Pascal Hambourg
2010-11-04 14:42                 ` H. Peter Anvin
2010-11-04 20:00                   ` Pascal Hambourg
2010-11-03 12:56     ` Pascal Hambourg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CD29423.6050009@earthlink.net \
    --to=sclark46@earthlink.net \
    --cc=davem@davemloft.net \
    --cc=hpa@zytor.com \
    --cc=jengelh@medozas.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pascal.mail@plouf.fr.eu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.