[nycbug-talk] Meeting content, format and future meetings
carton at Ivy.NET
Thu Jan 4 11:51:15 EST 2007
>>>>> "mh" == Michael Hanulec <hanulec at hanulec.com> writes:
yeah, the big step for users' groups seems to be to get enough
audience and presenter interest to have regular meetings about serious
topics at all. Everything else is easy by comparison.
mh> Ask Questions!
It's a little late, but I have some questions about PF!
(1) Did anything ever come of those rumors of integrating the IPsec
SPD into PF? Was it finished or deemed unfeasible?
(2) For those who have used ALTQ, why does PF's queue( a, b ) form
filter on the TOS bits? This simply doesn't work except on a
LAN---the bits are now DSCP rather than TOS, which means they're
altered on their way through the Internet. As soon as I set this
up and tried to measure its effect, the problem was immediately
obvious, and tcpdump quickly shows the cause. It's actually
harmful to force-provide this broken scheme along with the useful
ACK-prioritization scheme, because who knows how those bits will
arrive off the Internet.
(2.5) I think the form for matching TOS is broken, too---it implies
some kind of bitwise AND without documenting it. This breaks
matching DSCP. And there is no facility to set DSCP.
(3) PF 'keep state' rules are supposed to ``pass ICMP associated with
the TCP flow'', but they actually do *NOT* pass
ICMP-unreachable-fragmentation-needed from intermediate routers
between the two end systems. You have to pass these by hand with
a stateless rule. so there are actually a bunch, probably the
overwhelming majority, of PF routers out there misconfigured with
'keep state' only and thus causing the ``PPPoE problem'',
including my own router until recently, even though I understand
the problem. Shouldn't this configuration issue, which affects
basically everyone who uses PF, be documented accurately instead
of suggesting ``keep state is all you need'' like they do now?
Alternatively, 'keep state' should look inside all ICMP and match
it against the TCP flows by the ICMP payload instead of the
header. In any case, the issue which affects basically everyone
ought to be in the examples.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 304 bytes
Desc: not available
Url : http://lists.nycbug.org/pipermail/talk/attachments/20070104/7af5ce00/attachment.bin
More information about the talk