[nycbug-talk] Meeting content, format and future meetings
okan at demirmen.com
Thu Jan 11 10:21:41 EST 2007
On Thu 2007.01.04 at 11:51 -0500, Miles Nordin wrote:
> >>>>> "mh" == Michael Hanulec <hanulec at hanulec.com> writes:
> mh> constructive
> 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?
doh, the IPsec SPD into pf? i missed that rumor. why would you want the
SPD *in* pf? now, what is possible is tagging ipsec flows in ipsec.conf:
ike esp from any to 172.16.30.0/27 peer 64.90.xxx.xx tag voip
then in pf.conf:
pass out on egress tagged voip queue btlviop
> (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.
i don't know.
> (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.
if you are talking about mtu path discovery...it is not a pf issue if
admins don't know how to deal with this, and especially those you just
like to block icmp period.
if documentation is the issue, (i'll say it) submit a patch for the
manpages, being as clear and consise as you believe it should be. have
you read and understood pf.conf(5) completely? (it is in there)
> % NYC*BUG talk mailing list
> %Be sure to check out our Jobs and NYCBUG-announce lists
> %We meet the first Wednesday of the month
More information about the talk