Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 May 2016 17:46:22 +0300
From:      "Andrey V. Elsukov" <ae@FreeBSD.org>
To:        freebsd-ipfw <freebsd-ipfw@freebsd.org>
Cc:        lev@FreeBSD.org, luigi@FreeBSD.org, "Alexander V. Chernikov" <melifaro@freebsd.org>
Subject:   [RFC] ipfw named states support
Message-ID:  <573C803E.5020600@FreeBSD.org>

next in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Vi34AKBPEfaJOFBJxbJiTisvi4hUXiEvV
Content-Type: multipart/mixed; boundary="UHeLs31xeiCGEXG7DTxf9593DlPdPh3k7"
From: "Andrey V. Elsukov" <ae@FreeBSD.org>
To: freebsd-ipfw <freebsd-ipfw@freebsd.org>
Cc: lev@FreeBSD.org, luigi@FreeBSD.org,
 "Alexander V. Chernikov" <melifaro@freebsd.org>
Message-ID: <573C803E.5020600@FreeBSD.org>
Subject: [RFC] ipfw named states support

--UHeLs31xeiCGEXG7DTxf9593DlPdPh3k7
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi All,

We have the patch that adds named states support to ipfw.
The idea is that we add a symbolic name-label to each dynamic state in
addition to IP addresses, protocol and ports.
This introduces new syntax for check-state and keep-state rules:

  check-state { token | default | any }
  keep-state { token | default }

The @token can contain symbols from the following mask:
  [a-zA-Z0-9\-_\.]{1,63}

How it works
------------

"keep-state NAME" opcode creates state with assigned name NAME. This
state can be matched only by 'keep-state NAME' or 'check-state NAME', or
'check-state any' opcodes. The "default" name used for compatibility
with old rules. It is assigned to states when you omit the name on rule
creating. So,

# ipfw add check-state
# ipfw add allow ip from any to any keep-state

will produce:

  check-state default
  allow ip from any to any keep-state default

But there is one problem, when your rule has some opcodes after
'keep-state' opcode (e.g. "keep-state in"). Such opcodes can be treated
as state name.

'check-state any' matches states independently from the name.

Why we need this
----------------

This expands flexibility and functionality.
Imagine the situation:

[ LAN1 ] <---> [ FW ] <---> [ LAN2 ]

  add skipto 10000 ip from any to any via lan1
  add skipto 20000 ip from any to any via lan2
  add deny ip from any to any
  add 10000 count ip from any to any
  ...
  add allow ip from <lan1 nets here> to any keep-state in
  add deny ip from any to any
  add 20000 count ip from any to any
  ...
  add allow ip from <lan2 nets here> to any keep-state in
  add deny ip from any to any

The problem is that a state created by first keep-state rule will act on
second keep-state rule and allow traffic to go into (out from router's
point of view) lan2 without any rules actually allowing that.

With named states we can create separate states for each interface and
they will not match when we don't want this.

What I want to discuss
----------------------

1. Is this feature useful?
2. How to commit it? Due to changed syntax it can break existing
rulesets. Probably, we can add some mandatory prefix to state name, e.g.
':'.

--=20
WBR, Andrey V. Elsukov


--UHeLs31xeiCGEXG7DTxf9593DlPdPh3k7--

--Vi34AKBPEfaJOFBJxbJiTisvi4hUXiEvV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEbBAEBCAAGBQJXPIA+AAoJEAHF6gQQyKF6T/EH9Rnk0GO69LyOMQnyPTGsHGNp
VYK4elU8XDsuOLzfLKs+VO97upYHI+BmUvmzgFifpW7zWphSee2WR0PUUsM32gdy
hexIIbnpWS7mW4VeIfnUrOP2Un+j41i3cUGKDqNWThrebqeA9ERS+knNhbkeisiM
S5qM4UinEGMxbuGNwEYEZhbfkucj1+heNN6DkndnC/acMAL1fAyOqR8qsn8DMWW5
QH4UlduuxNTu4k4ezzYBmZcRI4RVCbPgJWVOemKVH0fxKkbK1368fpbMSlCgOARd
Zv32BcuzobuMMpSHYQ9vAhddjj5KNnrIFAK2mJRTaNmhJ4CjSZLE0Ae8DTEcTw==
=qS7k
-----END PGP SIGNATURE-----

--Vi34AKBPEfaJOFBJxbJiTisvi4hUXiEvV--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?573C803E.5020600>