* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 15:21 ` Jozsef Kadlecsik
@ 2012-07-01 16:52 ` Mr Dash Four
2012-07-01 21:30 ` Neal Murphy
2012-07-01 22:58 ` Amos Jeffries
2 siblings, 0 replies; 24+ messages in thread
From: Mr Dash Four @ 2012-07-01 16:52 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: netfilter, netfilter-devel, Patrick McHardy
> I have to weight the "great deal of inconsistency and inconvenience"
> caused to you against breaking firewall setups out there. I really
> appreciate your comments, but in this case you should adapt.
>
You are in no position to tell me what I should be doing. As for the
"breaking firewall setups" bit - see my previous comments.
Also, there is a flip-side to that particular coin - by keeping buggy
netfilter/kernel code, I'd argue that this is more likely to "break
firewall setups" as you put it - by keeping this, wrongful, setup and
the whole notion that for incoming IP addresses, subnets, ports and
everything else one should use "dst" designation, but for incoming
interfaces I should use "src" instead. I mean, really, get a grip of
yourself!
> Do you think all admins constantly read all changelogs, mailing lists
> about all the software they use to catch backward incompatible changes?
>
They do, if they're worth their salt.
> You are aware of the "inconveniece", and you could adapt yourself to it
> anytime.
Why should I, as a network admin, have to adapt to this buggy code just
because you just can't see what's in front of your face?
> I'm responsible for every user, for those who never read these
> mailing lists as well.
>
So, is ignorance an excuse nowadays? I never expected to read that from
a Netfilter developer, but there is a first time for everything I suppose.
> Feel free to involve anyone.
It is the only way I see forward as, evidently, "debating" this with you
is completely and utterly pointless - you are like a broken record,
repeating the same over and over and over again like an automaton.
> You argue that the meaning of src/dst for the interface part is
> counter-intuitieve and therefore must be reversed - regardless of the
> backward compatibility issue and the possible breaking of existing setups.
>
Where did I state, or even hinted that it is "counter-intuitive"? That's
right, I didn't. Because it is not "counter-intuitive", it is, at best,
wrong and inconsistent, at worse - buggy and downright misleading! Can
you read, Jozsef?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 15:21 ` Jozsef Kadlecsik
2012-07-01 16:52 ` Mr Dash Four
@ 2012-07-01 21:30 ` Neal Murphy
2012-07-01 21:55 ` Jan Engelhardt
2012-07-01 22:58 ` Amos Jeffries
2 siblings, 1 reply; 24+ messages in thread
From: Neal Murphy @ 2012-07-01 21:30 UTC (permalink / raw)
To: netfilter
Cc: Jozsef Kadlecsik, Mr Dash Four, netfilter-devel, Patrick McHardy
On Sunday 01 July 2012 11:21:51 Jozsef Kadlecsik wrote:
> Feel free to involve anyone. Just to sum up: in the case of the
> net:hash,iface type of ipset, the manpage says
>
> "The second direction parameter of the set match and SET target modules
> corresponds to the incoming/outgoing interface: src to the incoming one
> (similar to the -i flag of iptables), while dst to the outgoing one
> (similar to the -o flag of iptables)."
>
> You argue that the meaning of src/dst for the interface part is
> counter-intuitieve and therefore must be reversed - regardless of the
> backward compatibility issue and the possible breaking of existing setups.
FWIW, I think the existing semantics are spot-on.
- Where did this packet come from (what was its source)?
It came from src IF eth0.
- Where is this packet going (what is its destination)?
It is going to dst IF eth3.
Picture yourself standing in the middle of a (shallow) river. By Mr. Dash
Four's logic, upstream (where the water comes from) is the destination and
downstream (where the water is going) is the source; it's rather non-sensical.
A stream of packets, just like a stream of water, flows from its source toward
its destination. (A pedant might say that to swap 'source' and 'destination'
would be to pervert language. And language is about the only thing we can use
to communicate.)
Perhaps it would help to view netfilter as a small wayside in the universe of
IPv[46], rather than the center of that universe.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 21:30 ` Neal Murphy
@ 2012-07-01 21:55 ` Jan Engelhardt
2012-07-01 22:59 ` Neal Murphy
0 siblings, 1 reply; 24+ messages in thread
From: Jan Engelhardt @ 2012-07-01 21:55 UTC (permalink / raw)
To: Neal Murphy
Cc: netfilter, Jozsef Kadlecsik, Mr Dash Four, netfilter-devel,
Patrick McHardy
On Sunday 2012-07-01 23:30, Neal Murphy wrote:
>
>Picture yourself standing in the middle of a (shallow) river. By Mr.
>Dash Four's logic, upstream (where the water comes from) is the
>destination and downstream (where the water is going) is the source;
>it's rather non-sensical.
Must be a physicist thing. Electrons, those little but important things
giving us juice on the mains (which in most practical cases are solid
conductors), have also been declared to be negative. Just because.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 21:55 ` Jan Engelhardt
@ 2012-07-01 22:59 ` Neal Murphy
0 siblings, 0 replies; 24+ messages in thread
From: Neal Murphy @ 2012-07-01 22:59 UTC (permalink / raw)
To: Jan Engelhardt
Cc: netfilter, Jozsef Kadlecsik, Mr Dash Four, netfilter-devel,
Patrick McHardy
On Sunday 01 July 2012 17:55:32 Jan Engelhardt wrote:
> On Sunday 2012-07-01 23:30, Neal Murphy wrote:
> >Picture yourself standing in the middle of a (shallow) river. By Mr.
> >Dash Four's logic, upstream (where the water comes from) is the
> >destination and downstream (where the water is going) is the source;
> >it's rather non-sensical.
>
> Must be a physicist thing. Electrons, those little but important things
> giving us juice on the mains (which in most practical cases are solid
> conductors), have also been declared to be negative. Just because.
Physicists *are* known to have warped senses of humor. :) Electricity's the
only current flow I know of that is counter-intuitive on the surface. The flow
of electron *holes* defines current (+ to -), while electrons flow from - to
+.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 15:21 ` Jozsef Kadlecsik
2012-07-01 16:52 ` Mr Dash Four
2012-07-01 21:30 ` Neal Murphy
@ 2012-07-01 22:58 ` Amos Jeffries
2012-07-02 7:54 ` Jozsef Kadlecsik
2 siblings, 1 reply; 24+ messages in thread
From: Amos Jeffries @ 2012-07-01 22:58 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Mr Dash Four, netfilter, netfilter-devel, Patrick McHardy
On 02.07.2012 03:21, Jozsef Kadlecsik wrote:
> On Sun, 1 Jul 2012, Mr Dash Four wrote:
>
>> > the manpage, but it's totally counter-intuitive for you. Changing
>> the
>> > meaning might break working firewalls. Therefore the meaning won't
>> be
>> > changed.
>> >
>> This isn't simply a question of "meaning" - it is an issue caused by
>> the
>> fact that you have introduced something which, it seems, wasn't
>> properly
>> checked initially for whatever reason and that is causing a great
>> deal
>> of inconsistency and inconvenience for people, like myself, who use
>> ipset on a daily basis.
>
> I have to weight the "great deal of inconsistency and inconvenience"
> caused to you against breaking firewall setups out there. I really
> appreciate your comments, but in this case you should adapt.
>
>> When I match an incoming packet destined to an IP address for
>> example, I
>> have to use, quite rightly, a "dst" designation, but when I match
>> against the interface to which this same IP address belongs to,
>> according to your man page, I have to use "src" instead - all this,
>> simply because you didn't check this properly when hash:net,iface
>> was
>> first released and you can't be bothered, for one reason or another,
>> to
>> change it simply because "this has been out for a long time"?
>>
>> Do you think that all the network admins out there will have to
>> remember
>> to use "dst" when matching on destination IP addresses, port numbers
>> etc, but use exactly the opposite designation - "src" - when
>> matching on
>> the same destination interface that same IP address belongs to? Do
>> you
>> not see how inconvenient and downright misleading this is? If you
>> can't,
>> you are beyond hope, I am afraid.
>
> Do you think all admins constantly read all changelogs, mailing lists
> about all the software they use to catch backward incompatible
> changes?
> You are aware of the "inconveniece", and you could adapt yourself to
> it
> anytime. I'm responsible for every user, for those who never read
> these
> mailing lists as well.
>
>> Right, I am going to include Patrick in this as this whole saga is
>> becoming
>> something of a monologue and I need a bit of clarity on this.
>
> Feel free to involve anyone. Just to sum up: in the case of the
> net:hash,iface type of ipset, the manpage says
>
> "The second direction parameter of the set match and SET target
> modules
> corresponds to the incoming/outgoing interface: src to the incoming
> one
> (similar to the -i flag of iptables), while dst to the outgoing one
> (similar to the -o flag of iptables)."
>
> You argue that the meaning of src/dst for the interface part is
> counter-intuitieve and therefore must be reversed - regardless of the
> backward compatibility issue and the possible breaking of existing
> setups.
Jozsef,
just my 3c on this discussion to see if its any help.
As you say Mr Dash Four brings up a good point about confusion. It
certainly seems to confuse him/her, and very likely others with less
documentation reading experience.
IME the practice when this type of thing happens is good to find some
alternative clear naming for the parameters and to deprecate the old
ones. That allows the old names to be dropped from documented use, but
kept supported for existing config with a warning that admin need to
check the docs for new usage.
For myself, given the man page snippet it is clear what you intended
src/dst to be the "local" src/dst. But it is inconsistent with iptables
usages of src/dst and will trip up anyone not reading that page. Which
is not a good situation to be in.
Having been in that situation myself I sympathize and had this same
argument about the same scope concept with other developers several
times now. We usually end up using some form of "local" terminology for
the box internal details to differentiate from end-to-end scope
terminology. In this case --iface-ip / --oface-ip would probably be the
clearest contenders for your selection. But that is up to you.
/3c
HTH
AYJ
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 22:58 ` Amos Jeffries
@ 2012-07-02 7:54 ` Jozsef Kadlecsik
2012-07-02 13:11 ` Mr Dash Four
2012-07-10 16:27 ` Alex Bligh
0 siblings, 2 replies; 24+ messages in thread
From: Jozsef Kadlecsik @ 2012-07-02 7:54 UTC (permalink / raw)
To: Amos Jeffries; +Cc: Mr Dash Four, netfilter, netfilter-devel, Patrick McHardy
On Mon, 2 Jul 2012, Amos Jeffries wrote:
> As you say Mr Dash Four brings up a good point about confusion. It certainly
> seems to confuse him/her, and very likely others with less documentation
> reading experience.
>
> IME the practice when this type of thing happens is good to find some
> alternative clear naming for the parameters and to deprecate the old ones.
> That allows the old names to be dropped from documented use, but kept
> supported for existing config with a warning that admin need to check the docs
> for new usage.
>
> For myself, given the man page snippet it is clear what you intended src/dst
> to be the "local" src/dst. But it is inconsistent with iptables usages of
> src/dst and will trip up anyone not reading that page. Which is not a good
> situation to be in.
>
> Having been in that situation myself I sympathize and had this same argument
> about the same scope concept with other developers several times now. We
> usually end up using some form of "local" terminology for the box internal
> details to differentiate from end-to-end scope terminology. In this case
> --iface-ip / --oface-ip would probably be the clearest contenders for your
> selection. But that is up to you.
The issue is related to the hash:net,iface type alone and only the
interface part of the type: which interface is the "source" of the packet
and which one is the "destination". (There's no problem whatsoevert to
associate "src" and "dst" to the IP addresses/port/MAC of the packets.)
Maybe ASCII art helps better to explain the different views:
- Mr Dash Four
-----------
pkt comes in ----- | machine | ----- pkt goes out
^ ----------- ^
destination source
- my view follows how the subsytem sees the interfaces
------------------
pkt comes in --- interface | ipset subsytem | interface --- pkt goes out
^ ------------------ ^
source destination
As we learned, the latter is wrong and inconsistent, moreover buggy.
"src" and "dst" are generic keywords of the set match and SET target of
iptables/ip6tables and independent of the set types. The match and target
have no idea what is "src" and "dst", the given set interprets them
according to the type.
Also, it is not possible to introduce alternate keywords just for the sake
of the hash:net,iface, because ipset supports list of sets and in that
case the underlying sub-types are practically unknown to the match/target
(and additionally can be changed anytime).
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [ANNOUNCE] ipset 6.13 released
2012-07-02 7:54 ` Jozsef Kadlecsik
@ 2012-07-02 13:11 ` Mr Dash Four
2012-07-02 13:26 ` Jozsef Kadlecsik
2012-07-10 16:27 ` Alex Bligh
1 sibling, 1 reply; 24+ messages in thread
From: Mr Dash Four @ 2012-07-02 13:11 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Amos Jeffries, netfilter, netfilter-devel, Patrick McHardy
> Maybe ASCII art helps better to explain the different views:
>
> - Mr Dash Four
>
> -----------
> pkt comes in ----- | machine | ----- pkt goes out
> ^ ----------- ^
> destination source
>
> - my view follows how the subsytem sees the interfaces
>
> ------------------
> pkt comes in --- interface | ipset subsytem | interface --- pkt goes out
> ^ ------------------ ^
> source destination
>
>
How do you explain that the same "ipset subsystem" treats the IP address
of the "source" interface (according to your diagram above) as
"destination" when I match the same (incoming) packet above?
In other words, when I match a packet arriving on the "source" interface
(again, according to the diagram above) against the IP address this
"source" interface belongs to, I have to use "dst" designation, not
"src", but when I match it against the interface then I have to use
"src" instead? Also, how do you explain that the same designation
(destination) applies for everything else but the hash:net,iface set for
the same type of match (incoming packet)?
Give me a reasonable and coherent explanation and I'll accept your argument.
> "src" and "dst" are generic keywords of the set match and SET target of
> iptables/ip6tables and independent of the set types. The match and target
> have no idea what is "src" and "dst", the given set interprets them
> according to the type.
>
Regardless of whether the set match and SET target use these two
keywords, across the whole netfilter terminology, there is consistency
applied with the notable exception of the hash:net,iface and the "iface"
part in particular.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-02 13:11 ` Mr Dash Four
@ 2012-07-02 13:26 ` Jozsef Kadlecsik
2012-07-02 14:28 ` Mr Dash Four
0 siblings, 1 reply; 24+ messages in thread
From: Jozsef Kadlecsik @ 2012-07-02 13:26 UTC (permalink / raw)
To: Mr Dash Four; +Cc: Amos Jeffries, netfilter, netfilter-devel, Patrick McHardy
On Mon, 2 Jul 2012, Mr Dash Four wrote:
> > Maybe ASCII art helps better to explain the different views:
> >
> > - Mr Dash Four
> >
> > -----------
> > pkt comes in ----- | machine | ----- pkt goes out
> > ^ ----------- ^
> > destination source
> >
> > - my view follows how the subsytem sees the interfaces
> >
> > ------------------
> > pkt comes in --- interface | ipset subsytem | interface --- pkt goes out
> > ^ ------------------ ^
> > source destination
> >
> >
> How do you explain that the same "ipset subsystem" treats the IP address
> of the "source" interface (according to your diagram above) as
> "destination" when I match the same (incoming) packet above?
The source and destination IP addresses come of course from the packets.
They have nothing to do with the interfaces - one can route any (sort of)
packet with any source/destination IP addresses to whatever interface.
Do you skip routers and think of end hosts only, where the
destination/source IP address is that of the receiving/sending interface?
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [ANNOUNCE] ipset 6.13 released
2012-07-02 13:26 ` Jozsef Kadlecsik
@ 2012-07-02 14:28 ` Mr Dash Four
2012-07-02 20:26 ` Jozsef Kadlecsik
0 siblings, 1 reply; 24+ messages in thread
From: Mr Dash Four @ 2012-07-02 14:28 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Amos Jeffries, netfilter, netfilter-devel, Patrick McHardy
>>> Maybe ASCII art helps better to explain the different views:
>>>
>>> - Mr Dash Four
>>>
>>> -----------
>>> pkt comes in ----- | machine | ----- pkt goes out
>>> ^ ----------- ^
>>> destination source
>>>
>>> - my view follows how the subsytem sees the interfaces
>>>
>>> ------------------
>>> pkt comes in --- interface | ipset subsytem | interface --- pkt goes out
>>> ^ ------------------ ^
>>> source destination
>>>
>>>
>>>
>> How do you explain that the same "ipset subsystem" treats the IP address
>> of the "source" interface (according to your diagram above) as
>> "destination" when I match the same (incoming) packet above?
>>
>
> The source and destination IP addresses come of course from the packets.
> They have nothing to do with the interfaces - one can route any (sort of)
> packet with any source/destination IP addresses to whatever interface.
>
> Do you skip routers and think of end hosts only, where the
> destination/source IP address is that of the receiving/sending interface?
>
I see you are avoiding my questions as per usual, so I'll ask them
again, for the last time:-
1) Why is it that the same "ipset subsystem" in your diagram above
doesn't seem to apply the same criteria and treats the IP address of the
"source" interface as a "destination" (not "source"), in order to get a
match for the same type of (incoming) packet; and
2) How do you explain that the same designation ("destination") applies
for everything else in that "ipset system" (not to mention
iptables/netfilter) with the notable exception of hash:net,iface set for
the same type of match (incoming packet)?
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [ANNOUNCE] ipset 6.13 released
2012-07-02 14:28 ` Mr Dash Four
@ 2012-07-02 20:26 ` Jozsef Kadlecsik
0 siblings, 0 replies; 24+ messages in thread
From: Jozsef Kadlecsik @ 2012-07-02 20:26 UTC (permalink / raw)
To: Mr Dash Four; +Cc: Amos Jeffries, netfilter, netfilter-devel, Patrick McHardy
On Mon, 2 Jul 2012, Mr Dash Four wrote:
> > > > Maybe ASCII art helps better to explain the different views:
> > > >
> > > > - Mr Dash Four
> > > >
> > > > -----------
> > > > pkt comes in ----- | machine | ----- pkt goes out
> > > > ^ ----------- ^
> > > > destination source
> > > >
> > > > - my view follows how the subsytem sees the interfaces
> > > >
> > > > ------------------
> > > > pkt comes in --- interface | ipset subsytem | interface --- pkt goes
> > > > out
> > > > ^ ------------------ ^
> > > > source destination
> > > >
> > > >
> > > How do you explain that the same "ipset subsystem" treats the IP address
> > > of the "source" interface (according to your diagram above) as
> > > "destination" when I match the same (incoming) packet above?
> > >
> >
> > The source and destination IP addresses come of course from the packets.
> > They have nothing to do with the interfaces - one can route any (sort of)
> > packet with any source/destination IP addresses to whatever interface.
> >
> > Do you skip routers and think of end hosts only, where the
> > destination/source IP address is that of the receiving/sending interface?
> >
> I see you are avoiding my questions as per usual, so I'll ask them again, for
> the last time:-
>
> 1) Why is it that the same "ipset subsystem" in your diagram above doesn't
> seem to apply the same criteria and treats the IP address of the "source"
> interface as a "destination" (not "source"), in order to get a match for the
> same type of (incoming) packet; and
Nobody talks about the IP address of the interface - just you.
> 2) How do you explain that the same designation ("destination") applies for
> everything else in that "ipset system" (not to mention iptables/netfilter)
> with the notable exception of hash:net,iface set for the same type of match
> (incoming packet)?
I have wasted my time, so I stop here and the thread is ended for me.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-02 7:54 ` Jozsef Kadlecsik
2012-07-02 13:11 ` Mr Dash Four
@ 2012-07-10 16:27 ` Alex Bligh
1 sibling, 0 replies; 24+ messages in thread
From: Alex Bligh @ 2012-07-10 16:27 UTC (permalink / raw)
To: Jozsef Kadlecsik, Amos Jeffries
Cc: Mr Dash Four, netfilter, netfilter-devel, Patrick McHardy,
Alex Bligh
--On 2 July 2012 09:54:20 +0200 Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
wrote:
> - my view follows how the subsytem sees the interfaces
>
> ------------------
> pkt comes in --- interface | ipset subsytem | interface --- pkt goes out
> ^ ------------------ ^
> source destination
I have no comment on the back compatibility issue, but from a clean sheet
these interfaces should probably be called "ingress" and "egress"
interfaces (or, if you must 'input' and 'output' but those are ripe for
confusion with iptables rules). If those aren't the terms in the RFCs, they
are certainly terms of art commonly used by router vendors.
From my point of view, the current nomenclature is better than reversing
them (as I think is being proposed), but they are confusing in the case of
forwarded traffic where neither interface might be the 'source' or
'destination' in an IP sense. Swapping them would cause more confusion.
--
Alex Bligh
^ permalink raw reply [flat|nested] 24+ messages in thread