[nycbug-talk] Meeting content, format and future meetings

[Okan Demirmen]

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.

ditto.

> (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
> http://lists.nycbug.org/mailman/listinfo/talk
> %Be sure to check out our Jobs and NYCBUG-announce lists
> %We meet the first Wednesday of the month