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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
