Re: New DLT needed for PPP active/passiv filtering

[Karsten Keil <kkeil () suse de>]

On Tue, Aug 17, 2004 at 12:35:33PM -0700, Guy Harris wrote:
> (How I want a drink, alcoholic of course, after the heavy lectures 
> involving quantum mechanics.
>
> The above was inserted in the hopes that the duplicate message detector 
> won't flag this as a duplicate; it was originally sent from an address 
> of mine not on the tcpdump-workers list, and rejected for that reason.)
>
> On Aug 17, 2004, at 3:53 AM, Karsten Keil wrote:
>
> > between libpcap version 0.7 and 0.8 the DLT_PPP was cleaned up to not 
> > longer
> > support the faked IN/OUT flag which was needed to compile filter rules
> > for the PPP activ/passiv filtering.

Typo of mine, activ and pass filter, not passiv.

Activ filter: only for DIAL ON DEMAND and hangup timeout, pakets are only
              classified to reset the timeout counter or not and
              if they are allowed to trigger a dialin.

Pass filter:  a filter to drop unwanted pakets like a firewall
 

> > The cleanup is OK, since the nativ PPP frame do not have any IN/OUT 
> > flag,
> > so for traffic analysers it is confusing to have a faked first byte.
>
> More importantly, there *was* no faked first byte, so the older 
> versions of libpcap didn't really "support" the IN/OUT flag - it 
> generated code that assumed it was there, but, because it wasn't there, 
> that code didn't work correctly on normal PPP captures.

It was here in the PPP filter context. The normal 4 byte header looks like:

FF 03 <P1> <P2>     P1 P2 give a 16 bit protocol ID for identyfy the data
following the haeder, which maybe PPP control data or IP/IPX payload data. 
Since the PPP filtering is only called for IP/IPX payload frames, the
constant FF byte was redefined as IN/OUT Flag (1 := OUT, 0:= IN).
Note: The Filter is called after doing all decompression, so its allways
a simple PPP payload data frame (in case of outgoing, it is called before
doing compression or add multilink headers).

> Note also that, for any DLT_PPP packets that *did* have an extra first 
> byte in the header, any *other* filter expression wouldn't work, as the 
> rest of the code for PPP assumed that it *wasn't* there.

It was no extra byte, it was the first redefined byte of the PPP header,
which is not used for tests in normal cases. Only tests which explizit check
that FF 03 is present did not work correctly.


> > But for activ/passiv filtering, which is needed to determine for dial 
> > on
> > demand which pakets are allowed to create a new connection or which 
> > pakets
> > hold the current connection open, it is a strong demand to differ 
> > between
> > own (OUT) and incoming traffic (which may contain unwanted pakets, like
> > port scans or pakets from old lost connections (dynamic IPs maybe
> > reassingned).
>
> So how exactly are those packets delivered to a filter?  I assume they 
> aren't being delivered on a PF_PACKET socket.

Yes, the kernel PPP code calls the sk_run_filter directly with this 
paket format <I/O><03><P1><P2><payloaddata IP or IPX> (IP or IPX is 
defined by P1/P2, but only IP was used so far I know).

In the case, that here is no activ connection, the kernel send the
outgoing pakets to the pppd daemon which calls the libpcap
bpf_filter() function (dial on demand).

> > A solution may be to create a new DLT_PPP_INOUT (better names welcome),
>
> DLT_PPP_WITHDIRECTION, or something such as that?

Sounds good for me.

> > which take the first PPP byte, which is not needed for filtering as 
> > IN/OUT
> > Flag (same behavior as libpcap 0.7 DLT_PPP had).
>
> I.e., the link-layer header for the new DLT_ has a one-byte IN/OUT 
> flag, followed by a regular PPP header?

It has the regular PPP header, with the exception that the first byte
is not FF, but used as IN/OUT flag.

 
> > This solution is backward compatible and need no changes in the PPP 
> > core
> > routines. Old ppp binary (libpcap 0.7 based) will still work.
>
> ...as long as the only thing being checked is the IN/OUT flag (unless 
> "libpcap 0.7 based" means that it was changed to assume that extra byte 
> is there).

-- 
Karsten Keil
SuSE Labs
ISDN development
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.