[ipv6hackers] Requirements for IPv6 firewalls (new IETF-ID)

[Fernando Gont]

Hi, Robert!

Thanks so much for your feedback! Please find my comments in-line...

On 02/20/2014 08:35 AM, Sleigh, Robert wrote:
> 
> As "connections" from an FW perspective are not necessarily TCP, should
> you define and use additional phrases like "stateful sessions"? eg a DNS
> UDP "connection" still should be able to be timed out, to protect resources.

At times I use the term "transport protocol instance" -- which is good
enough for say TCP and UDP, but certainly not for ICMPv6 (since it's not
a transport protocol).

How about if we add a "terminology" section, where we define terms that
we use (such as e.g. "stateful sessions"  (or maybe just "session", as
in "TCP session", "ICMPv6 session", etc.) and then use then consitently
throughout the document?



> GEN-4:
> 
> I know this seems to go against the main thrust of the currents req, but
> is there any wider interest for including the ability to retain some
> connections indefinitely? This would clearly also need to be selectively
> deployed.
> 
> So I think your proposal identifies that having just a default
> inactivity timer is inappropriate for many situations, and highlights
> the need to be able to reduce it for certain situations.

The intent wasn't to mandate default timeouts, but rather to require
this capability (such that an admin can enable and configure them if
deemed desirable).



> In the mobile network world of always-on devices using IPv4,
> applications end up sending keep-alive packets partly to ensure FWs do
> not timeout long-lived but quiescent connections. Worse even than that,
> some IPv4 FWs I've worked with have an overriding default timer which
> drops sessions after, say 24 hours, irrespective of activity or lack of it.

This is something that would be great to clarify, such that
implementations don't get it wrong (good point!).



> So I'd propose that the timers should be adjustable both up and down,
> and with more granularity, so selectable by more than just protocol:

Yep. The intent is there should be different timeout, for different
aspects. e.g., for TCP there could be timeouts for different states (I'm
not necessarily proposing it.. it's just an example).



> SPC-4:
> 
>  
> 
> Is a repeat of SPC-1

Good grief! -- I've just removed it.

Thanks!

Best regards,
Fernando




-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492