Subject: [SAVA] regulatory requirements (a concrete example)

From: pekkas at netcore.fi (Pekka Savola)
Date: Tue Mar 20 17:25:55 2007

Hi,

The regulatory anti-spoofing requirements heard at the BOF were rather 
unclear, maybe because thos didn't exist yet :-).

As a more concrete example, Finland has already in force a regulation 
that requires among the others the following (roughly translated):

  - in ISP interconnections both ISPs are responsible for preventing
    forwarding traffic from source addresses not advertised by the
    sending ISP. [[ note: this is actually a very strict "you must
    filter based on routing advertisements" requirement, currently not
    widely honored in Finland ]]

  - in received route advertisement, ISP must reject routes to your own
    netblocks unless there is agreement for otherwise for a specific
    netblock [[ note: e.g., a historical PA address block that has
    changed ISPs ]].

  - ISP must filter its own source addresses from incoming traffic
    unless there is explicit agreement to do otherwise.

  - ISP must prevent directed-broadcasts at all interfaces.

  - ISP must meticulously document all their advertisements in a public
    Internet routing registry.

  - Transit ISPs must take care that their customers' advertisements
    are similarly recorded in IRR.

  - When ISP uses a non-allocated or special address prefix lists
    (e.g., 'bogons'), it must take special care to keep it up-to-date.

(Specifically, these are written in such a manner that you should be 
able to run even feasible paths strict uRPF between ISPs if the ISPs 
conformed to the regulatory requirements.  No protocol work is needed 
in this case.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: danny at tcb.net (Danny McPherson)
Date: Tue Mar 20 19:10:11 2007

On Mar 20, 2007, at 3:24 AM, Pekka Savola wrote:

> Hi,
>
> The regulatory anti-spoofing requirements heard at the BOF were  
> rather unclear, maybe because thos didn't exist yet :-).
>
> As a more concrete example, Finland has already in force a  
> regulation that requires among the others the following (roughly  
> translated):

I commend the folks that helped get this in place..  A couple
of questions..

Where is this regulation defined?

Has it ever been enforced, and is there any indication of what
such an enforcement might look like?

>    widely honored in Finland ]]

Does this apply to any SP operating in Finland, I presume so?

>    Internet routing registry.

Are there public IRRs defined/recommended for this purpose, or at
least preferred IRRs, or...?

>    are similarly recorded in IRR.

Is there anything there about actually filtering route advertisements
egress and/or ingress based on those IRR records?

>    (e.g., 'bogons'), it must take special care to keep it up-to-date.

Is 'prefix lists' in this context strictly defined somewhere?  E.g.,  
does
it apply solely to route advertisement or to data plane functions as
well?  Also, are 'bogons' defined or referenced, and if so, to where?

> (Specifically, these are written in such a manner that you should  
> be able to run even feasible paths strict uRPF between ISPs if the  
> ISPs conformed to the regulatory requirements.  No protocol work is  
> needed in this case.)

Do you believe this has made any difference (i.e., do folks in Finland
care)?

-danny

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Tue Mar 20 20:38:43 2007

Some further details on the Finnish regulatory example..

> Where is this regulation defined?

In Finnish regulatory body's (www.ficora.fi) "normative statements" 
(not sure of the right term), the normative power of which is based on 
two laws.

> such an enforcement might look like?

It hasn't been enforced to my knowledge.  It only came in force in 
1.1.2006.   If you fail to comply, you may get fined.

I'll likely try this out at some point myself by complaining about a 
couple of noncompliant networks (in particular, inproperly filled IRR 
data which hasn't been fixed despite requests) to the regulator, and 
see if a letter to the offending company's lawyer will change their 
minds :-)

> Does this apply to any SP operating in Finland, I presume so?

Basically yes.

...
> least preferred IRRs, or...?

Not normatively, but the recommendations say RIPE DB and that's also 
typically used.

> egress and/or ingress based on those IRR records?

Not a separate requirement, but combining this with the first 
requirement ("announce everything you source traffic from; recipient 
should filter out those packets whose routes aren't advertised"), it 
boils down to this.  If your peer is adhering to the regulations, you 
should be able to use IRR-based filtering to filter both routing data 
and packets.

> Is 'prefix lists' in this context strictly defined somewhere?  E.g., does

I was using shortcuts in translation :-).  It applies to both. A more 
precise and complete translation might be like:

  - When an ISP uses a filtering ruleset based on special-purpose or
    unallocated address space to filter traffic or routing information,
    the ISP must take special care to keep the rulesets up-to-date.

>> (Specifically, these are written in such a manner that you should be able 
>> to run even feasible paths strict uRPF between ISPs if the ISPs conformed 
>> to the regulatory requirements.  No protocol work is needed in this case.)
>

This is still rather recent, but we've cited the requirement when 
sending mails to our peers asking them to fix their IRR registrations. 
Many have fixed them; others have not responded.

If I recall correctly, most ISPs seem to be in agreement that they are 
not foreseeing putting in IRR-generated or uRPF-based anti-spoofing 
ingress filters between each other, but I think most would be willing 
to comply with the rest of the requirements.

I guess the next step to test is to ask the regulatory body to look 
into specific issues I've noted and see what kind of action will 
result :-)