Hi, Ivan:
Thanks for your thoughtful review. We'll be incorporating
many of your suggestions into the next revision.
On 9/1/12 6:36 AM, Ivan Pepelnjak wrote:
In general, I find the draft way too vague (particularly sections 6 &
7, so I made no comments on them). I know state migration is a very
difficult problem, so maybe you should limit yourself to a smaller
and manageable subset, for example VM migration.
Scoping this (and most IETF problems) is difficult, and it's
something we've gone around and around on. I expect that if
the SOCKS authors hadn't been so intransigent about NAT, much
of the firewall discussions we've been having for the last, oh,
15 years or so would not have been necessary, but scoping is
hard and they didn't want to bite off too much. Anyway, I
think your point is valid but I'm not sure yet that we know
exactly how to scope the problem in a way that will be small
enough to solve on the one hand and not so narrow as not to
be useful on the other. I'm hoping that we can have a BOF
in Atlanta to be able to have this discussion in real-time.
Major remarks ============= 4.1 - What is state =================== *
The flow 5-tuple (section 4.1) is the _flow classifier_ (and even the
5-tuple would often include context like VRF or VLAN). There are
usually _actions_ associated with the flow (FW: permit, log ...,
LB,NAT: source or destination rewrite). It might make sense to import
ideas from OpenFlow documents.
I think at this point we're trying to focus on abstractions
that will be applicable across a range of firewalls. I had
hoped that the notion of the *action* being migrated along
with the 5-tuple (or other descriptive information) would be
implicit in the discussion, but you're right that it should
be explicit.
4.2 - State versus Policy ========================= I found the whole
section confusing. I always thought the policies were (in general)
hierarchical set of classifiers and actions, and when a flow state is
created, a list of policy actions gets attached to the flow.
It certainly can be, but this discussion was at a higher level.
You're describing an instance of "policy." Unfortunately there's
no clear definition of state that I could find in existing IETF
documents, and "policy" tends to be associated with specific
policies in particular protocols.
4.3 - Instantiating state ========================= I don't
understand what the mechanisms for policy creation (and consumer
equipment in particular) have to do with this draft. Keep it simple
and state that the mechanisms used to create policies are
out-of-scope.
Well, they're not, really, in that in some cases participants
in a session/flow may not know that there's middlebox state
associated with them. If they use some mechanism to explicitly
instantiate the state, they will. This has considerable
impact on where to place an agent that will be responsible
for managing (for lack of a better term) a state migration.
Also, there's no "hybrid mechanism". Either the middlebox supports a
state signaling protocol (ex: RSVP) or not. STUN is just a necessary
kludge trying to guess properties of adjacent NAT devices and using
them to its advantage.
No, this is not correct. STUN may be used to create the NAT table
mapping, since in a typical case (VoIP, say) the endpoint or its
call control server cannot know what media addresses to embed in its
signaling messages until it's somehow gotten that address. No actual
media traffic have flowed yet. Even in this case STUN does not
communicate directly with a NAT, but works by side-effect.
We'll be getting a revised draft out prior to the next meeting, and
as I mentioned I hope that we'll be able to have a (short) BOF to
try to get a handle on some of these issues.
Melinda
