Pekka Savola wrote:
On Wed, 5 Mar 2008, IETF Administrative Director wrote:
The IAOC has published the IETF Meeting Network Requirements ION at
http://www.ietf.org/IESG/content/ions/
The purpose of the document is to assist IETF meeting Hosts and technical
teams with the network requirements in support of the week-long IETF
meetings.
Editors were Karen O'Donoghue, Jim Martin, Chris Elliott, and Joel
Jaeggli whose hard won experience with designing and deploying these
networks will serve others well.
Not sure how relevant this is given the earlier ION statement, but a
few things I'd like to clarify in this:
- S3 has "All locations for network gear, with the exception of
wireless APs, MUST be secure."
What does "secure" mean in this context? My observation is that this
may the case if secure means "physically attached so that no one
should, without big hassle, be able to steal the device".
Secure means IDF/MDF facilities are controlled access, a door with a key
is observed to be sufficent. It is generally understood that meeting
rooms and public spaces are no-more-secure than they people in them.
A certain amount of tampering with in-room equipment is inevitable and
is generally addressed with instrumentation.
If "secure" means something else, for example, "impossible to fiddle
with cabling, e.g. add your own laptop as a bridge to the uplink port,
capturing all traffic" this does not follow existing practice (I
observed at IETF71 that there were a number of switches which were
stealing-secure but not tampering-secure).
- S4 has "The network MUST NOT prohibit end-to-end external
connectivity for asy traffic (no limiting firewalls or NATs)".
Does this also disallow (rather typical) filtering of "Windows ports"
(at least 137-139, 445)?
I understand it to mean that yes, the advisability of using SMB across
the public internet notwithstanding.
I would expect that a meeting network provider would respond to threats
to the functionality of the network as they appear but not prohibit
traffic unless it is deems harmful. The requirement was aimed at the
design considerations rather than actual operation ie no stateful
firewall ruleset, no natting the whole meeting, no filtering ports to
discriminate against certain kinds of applications etc...
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf