[Top] [All Lists]

Re: Meeting Network Requirements ION Published

2008-03-25 10:04:20
Pekka Savola wrote:
On Wed, 5 Mar 2008, IETF Administrative Director wrote:
The IAOC has published the IETF Meeting Network Requirements ION at

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

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

<Prev in Thread] Current Thread [Next in Thread>