On Tuesday, March 15, 2005, at 09:44 AM, Brian E Carpenter wrote:
I think this is why we chartered MIDCOM in the first place.
Yes, and midcom as currently specified does support firewall attributes.
To get back to the broader questions, when we set out to do midcom and
to address the general problem of middleboxes our priorities included
restoring, to the extent possible, end-to-end function, and "security"
where security included both securing the protocol itself as well as
not interfering with end-to-end security, which really is a terrible
problem with many types of middleboxes.
As NAT traversal work has gone forward in other parts of the IETF I
think those priorities have been lost, or at least shifted down the
list. That's not a good thing. I think part of the problem has been
that telecomm-type applications tend towards heavy mediation of
control data and some mediation of user data. Another problem is a
real-world problem, and that's that it's a lot easier to throw new
crap into a network than it is to modify what's already there. I'm
not sure how to solve that particular problem, but while I disagree with
Tony's proposed solution to the NAT situation I think he's 100% correct
in his characterization of it.
I'd like to see the IETF refocus its NAT traversal efforts on trying
to adhere to good architectural principles. If that's too airy,
perhaps the question should be framed as whether or not the proposed
mechanism allows securing communication between two endpoints.
Melinda
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf