FICIX peering etiquette
=======================
version 1.0 20-Jan-2005

Purpose

This document set guidelines for running a peer-friendly network.
Peers are valuable, and good peers are even more valuable.
Guidelines are not rules, but more or less just a check-list to
run through once and awhile.

1.	Emergency and routine maintenance

Maintenance is essential to gain optimal network operation and security.
Maintenance may introduce flapping, instability or NLRI reachability effects
to peers. Therefore it is good practise to inform peers about emergency
situations, as well as scheduled maintenance.

 1.1	Publish your maintenance window and inform about emergency situations.
In case the maintenance is known to consern IXP connectivity, sufficient
notice time is three (3) working day beforehand.
 
2.	Communications

Running a 24/7 staffed NOC is probably the best way to deal with
troubleshooting and network reliability overall. The existense of such NOC
is not much of use if peers do not know how to reach it, or if the NOC
doesn't know how to communicate with peers.

 2.1	Publish your NOC connectivity details: phone number, email address(es)
and URL of networks status (if available), and train NOC how to reach
other peers.

3.	Routing Best Practices

 3.1.	Peers should register in advance their routes, routing domains,
and routing policies of its public Internet subscribers in a public
Internet Routing Registry. Each peer shall exercise good faith efforts to,
as soon as reasonably possible, implement configuration changes to match
changes in Internet Routing Registry policy. 

 3.2.	Peers should not send routes corresponding to Third Party Networks.
If, without notice to the other peer, either peer detects such routes,
it shall have the right to block such routes.

 3.3.	Peers should not send traffic across the Interconnection Points towards
the Network of the other peer, other than traffic which has a destination
which lies within the Routed Network of that other peer, as determined by
their BGP-4 advertisement at the time.

 3.4.	The peers shall maintain a consistent routing announcement. The peers
will present the same Autonomous System number at all mutually agreed
Interconnection Point(s). The peers shall announce the same routes at
Peering Sessions at each Interconnection point. Each peer shall ensure
that the BGP-4 attributes of each route it announces in each peering session
is identical to those of that route in all other peering sessions, with
the exception of the 'next-hop' attribute, and the 'MED' or 'Metric' Attribute.

 3.5.	Peers should have practices to minimize route flap's as much as
possible to avoid unnecessary updates as well to conserve processing
at both ends of peering.
 
 3.6.	Peers should not advertise unnecessarily specific routes in
its Peering Sessions. 

 3.7.	Peers should not advertise routes with a next-hop other than
that of one of its own routers. 

 3.8.	Each peer agrees, on all interfaces connected to an Interconnect,
to disable: Proxy ARP, ICMP redirects, Directed broadcasts,
IEEE802 Spanning Tree, Interior routing protocol broadcasts, and all
other MAC layer broadcasts except ARP. 

4.0 	Security Best Practices

 4.1 Abuse contact info

Each peer should publish an abuse -contact that is working (monitored).

 4.2. SPAM

Each peer should define and publish SPAM policy in AUP (Acceptable Usage Policy).
Peers should commit to control and hamper SPAM activity to reasonable extend,
including filtering open SMTP relay -sites and preventing access to the network
from infected workstations acting as SPAM generators.
National co-op between finnish authorities and operators is SIT-group,
lead by Ficora (www.ficora.fi).  Peers are encouraged to participate this work.
SIT (Sähköposti- ja Internet-yhteyspalvelujen tietoturva ja toimivuus).

 4.3. Denial Of Service

Peers are encouraged to implement well known DOS (or DDOS) prevention and self
protection shemes. These schemes include RPF check at border gateways, various
filtering mechanism concerning NLRI announcements and packet filters, and
BGP community based null_routing of DOS target IP host address.

 4.4. Network fraud (like phishing)

Peers should commit to control network fraud to reasonable extend, including
filtering decepted -sites and preventing access to the network from infected
workstations acting as nodes for malware distribution.

 4.5. CERT co-operation

Peers should get contact with finnish CERT authority (CERT-FI) at Ficora,
at least by subscribing to CERT mailing list. CERT-FI can be reached at
cert@ficora.fi and www.ficora.fi.

-- EOF