Subject: Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 9 Nov 2016 18:59:53 +0000

Nick,

Thanks for your comments.

>this looks difficult to implement and easy to spoof.  urpf is already hard enough to implement in hardware and my understanding is that it usually requires either packet recirculation for the SAV process or else a separate source address lookup per packet.  If this lookup process is tied into other validation mechanisms which aren't available in the forwarding engine (e.g. common source ASN, etc), then there would be a requirement to punt packets, which is not viable.

The common source ASN checking is performed on BGP updates 
in the control plane (not in the data path), and that results in 
adding some additional allowed prefixes (for particular interfaces) to the 
Reverse Path Filter (RPF) list for SAV. I don't think this would result in 
other validation mechanisms which aren't available in the forwarding engine.
The data plane would perform the usual uRPF check: Does the SA in the data packet 
belong in a prefix in the RPF list for the interface it was received on?
So there shouldn't be any requirement to punt data packets.

If there are specific implementation details that I should be aware of, 
please let me know. I would be very interested.

Sriram

-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]]
Sent: Tuesday, November 01, 2016 12:16 PM
To: Sriram, Kotikalapudi (Fed) <[email-masked]>
Cc: [email-masked]
Subject: Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

Sriram, Kotikalapudi (Fed) wrote:
> This work has been submitted to OPSEC WG.
> Posting here also since it may be of interest to GROW WG members as well.
> Comments/suggestions on this draft are welcome -- here or on the OPSEC list.
> Thank you.

Sriram,

this looks difficult to implement and easy to spoof.  urpf is already hard enough to implement in hardware and my understanding is that it usually requires either packet recirculation for the SAV process or else a separate source address lookup per packet.  If this lookup process is tied into other validation mechanisms which aren't available in the forwarding engine (e.g. common source ASN, etc), then there would be a requirement to punt packets, which is not viable.

Could you explain how feasible urpf can avoid this situation?

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 09 Nov 2016 20:09:14 +0000

> So there shouldn't be any requirement to punt data packets.

right, ok - I misunderstood.  So you're suggesting that the control
plane correlates asns to interfaces and does something like creating a
higher cost alternative path out each candidate source interface (based
on ASN, as determined in the control plane) to allow the urpf mechanism
handle this using its normal lookup method?

Nick

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 9 Nov 2016 20:34:14 +0000

>> The common source ASN checking is performed on BGP updates in the 
>> control plane (not in the data path), and that results in adding some 
>> additional allowed prefixes (for particular interfaces) to the Reverse 
>> Path Filter (RPF) list for SAV. I don't think this would result in 
>> The data plane would perform the usual uRPF check: Does the SA in the 
>> data packet belong in a prefix in the RPF list for the interface it was received on?

>right, ok - I misunderstood.  So you're suggesting that the control plane correlates asns to interfaces and does something like creating a higher cost alternative path out each candidate source interface (based on ASN, as determined in the control plane) to allow the urpf mechanism handle this using its normal lookup method?

Yes, that is correct.

Sriram

---

From: Gert Doering <[email-masked]>
Date: Thu, 10 Nov 2016 16:19:14 +0100

Hi,

> belong in a prefix in the RPF list for the interface it was received on?

This, actually, is not "the usual uRPF check".

Having implementations that could tack arbitrary "RPF lists" to an 
interface would be very nice, but this is more like "auto-generate ACLs
based on prefix info" than "RPF" which stands for "reverse path filter"
(not sure about the "filter" bit, though)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 10 Nov 2016 23:12:08 +0000

Sriram, Kotikalapudi (Fed) wrote:
>> plane correlates asns to interfaces and does something like
>> creating a higher cost alternative path out each candidate source
>> interface (based on ASN, as determined in the control plane) to
>> allow the urpf mechanism handle this using its normal lookup
>> method?
> 
> Yes, that is correct.

I can't help feeling that the use case looks a bit contrived.  The sort
of situations that could benefit from urpf that I've seen on production
networks don't generally involve inconsistent prefix sets being
announced via different connectivity providers, where there is a
requirement for urpf away from the leaf network.

If it's any help, the most usual situation where urpf would be handy but
can't be done, is where you have an interface facing an upstream and you
want to receive prefixes (and send traffic) via that interface but not
announce anything (or receive traffic).

Nick

---

From: joel jaeggli <[email-masked]>
Date: Sun, 13 Nov 2016 12:29:59 +0900

> announce anything (or receive traffic).

The case where routine maintance creates temporary blackholes is
basically ubiquitious were you attempting to use urp strict.

> Nick
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 13 Nov 2016 11:12:08 +0000

> basically ubiquitious were you attempting to use urp strict.

oh indeed - I've been at the receiving end of exactly this type of
blackholing.  Very annoying.  But I just wonder if urpf is the best tool
to hammer this particular nail in.  Sriram implicitly points out that
the term "customer cone" is a rather vague concept, and once you add the
vagaries of peering cones, it gets a lot worse.  From an anecdotal point
of view, people route traffic all over the place, and the further you
get away from the traffic endpoints, the more difficult
source-validation filtering becomes.

I suspect Sriram's proposed methodology is not going to be as useful as
it might seem in production networks because he's making an assumption
that the list of valid source paths can be built up by creating a union
of all source ASNs and applying that to the union of all interfaces
which are identified as feasible paths, intersected with the list of
interfaces with feasible path urpf enabled.  Going back to his diagram,
what if AS1 announces a prefix over a different transit e.g. AS6, but
not AS4 or AS5?  Then they issue traffic with a source address from that
prefix. The only way to handle this situation is with loose urpf, which
is a nice way of saying that enhanced urpf would cause breakage in this
situation.

I'm raising this because we run an as112 server at INEX and we've
observed a surprisingly large quantity of traffic directed towards the
anycast address from IP addresses from all over the world which come
over the IXP fabric, but which we can't imagine how it arrives there,
e.g. traffic from apnic + latam regions, etc.  While I appreciate that
this is anecdotal, it's a real enough observation for me to suspect that
the level of decoupling between bgp announcements (i.e. return path
traffic) and forward path routing is something that would cause enhanced
urpf to cause blackholing on production networks.

Nick

---

From: joel jaeggli <[email-masked]>
Date: Mon, 14 Nov 2016 06:22:54 +0900

> is a nice way of saying that enhanced urpf would cause breakage in this

Yeah, loose, ends up being the limit of was is feasible; you might as
well deploy a bogon filter drop martians, and not bother.

> urpf to cause blackholing on production networks.

The preference of some networks to trump regional  preference with free,
to participate in mlpe exchages, without announcing routes on them, or
to selectively announce routes only to certain participants, while
witholding them from others makes all sort of wierd stuff appear there.
it makes to hard or more likely impossible to apply such filtering on
IXP ports.

In our case, where we generate prefix list filters for all routes that
we accept into the rib at exchange points we are naturally not even
going to have all of the paths that may potentially be available there.

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 15 Nov 2016 03:05:01 +0000

Nick,

My responses marked with [Sriram].

[Nick] I suspect Sriram's proposed methodology is not going to be as useful as
it might seem in production networks because he's making an assumption
that the list of valid source paths can be built up by creating a union
of all source ASNs and applying that to the union of all interfaces
which are identified as feasible paths, intersected with the list of
interfaces with feasible path urpf enabled.  

[Sriram] That description is confusing. The description I would provide is: 
The ISP's AS creates a union of all announced prefixes that have a common origin AS.
Those announcements have potentially been received 
on various customer/ peer/ provider interfaces.
Take that union of prefixes and include it in Reverse Path Filter (RPF) tables 
on all interfaces on which one or more of the prefixes in the union were announced.

[Nick] Going back to his diagram,

[Sriram] This (your) scenario still works with the above clarified description of the method.
The bottom line is: Wherever feasible path uRPF method is used currently, 
the enhanced FP uRPF method would work and with greater robustness.

Sriram

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 15 Nov 2016 03:12:40 +0000

Gert,

My response marked with [Sriram] below.

[Gert] Having implementations that could tack arbitrary "RPF lists" to an
interface would be very nice, but this is more like "auto-generate ACLs
based on prefix info" than "RPF" which stands for "reverse path filter"
(not sure about the "filter" bit, though)

[Sriram] Current Feasible Path uRPF makes use of announced prefixes
to creates RPF tables of permitted source addresses on specific interfaces,
and our enhanced FP uRPF also does the same, but with some more
intelligence built in.

Sriram

---

From: Job Snijders <[email-masked]>
Date: Tue, 15 Nov 2016 12:48:36 +0900

On Tue, Nov 15, 2016 at 03:12:40AM +0000, Sriram, Kotikalapudi (Fed) wrote:
> [Gert] Having implementations that could tack arbitrary "RPF lists" to
> an interface would be very nice, but this is more like "auto-generate
> ACLs based on prefix info" than "RPF" which stands for "reverse path
> filter" (not sure about the "filter" bit, though)
> 
> [Sriram] Current Feasible Path uRPF makes use of announced prefixes to
> creates RPF tables of permitted source addresses on specific
> interfaces, and our enhanced FP uRPF also does the same, but with some
> more intelligence built in.

Does this technique make routers self-aware? What exactly is meant with
the word 'intelligence' in this context?

Kind regards,

Job

---

From: joel jaeggli <[email-masked]>
Date: Tue, 15 Nov 2016 13:53:08 +0900

>> more intelligence built in.

generating prefix lists for peers is something done out of band...

e.g. by bgpq3

the information does not exist in the routing system to do that e.g. for
prefiexes which are not presently announced or not announced to you, in
particular before sessions are established.

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 15 Nov 2016 05:38:57 +0000

>the word 'intelligence' in this context?

'Logic' may be a better choice than 'intelligence' in this context?
For a brief description of the algorithm, please see:
https://www.ietf.org/mail-archive/web/grow/current/msg03699.html 

Sriram

---

From: Job Snijders <[email-masked]>
Date: Tue, 15 Nov 2016 17:26:53 +0900

On Tue, Nov 15, 2016 at 05:38:57AM +0000, Sriram, Kotikalapudi (Fed) wrote:
> > Does this technique make routers self-aware? What exactly is meant
> > with the word 'intelligence' in this context?
> 

Thank you for the clarification.

I have a second scenario that might be a challenge for Enhanced
Feasible-Path uRPF.

ASCII ART:

		+---+
	  +-+AS1+--+
	  | +---+  |
	  |        |
	  |        |
	+-+-+    +-+-+
	|AS2|    |AS3|
	+---+-+  +--++
		  |     |
		  |     |
		+-+-+   |
		|AS4+---+
		+---+

AS4 is a customer of AS2 and AS3. AS4 ingests a full routing table from
both AS2 and AS3 (and as such as two paths to AS4).

A common traffic engineering practise visible in the Default-Free Zone
is to block unbounded propagation of one's prefixes. For instance, AS4
might use a BGP Community provided by AS2 to block propagation of the
AS4 prefixes to AS1 via AS2. The equivalent would be that AS4 attaches
NO_EXPORT on the announcements to AS2, but not on the announcement to
AS3.

AS1 will receive traffic sourced by the prefixes from AS4 via both
AS2_AS4 and AS3_AS4.

Kind regards,

Job

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 15 Nov 2016 09:13:16 +0000

I understand the scenario.
That scenario is a problem for strict or feasible path uRPF, as well as the enhanced FP uRPF.
If you add one further generalization to enhanced FP uRPF,
namely, allow any prefix learned on any customer peering
to be included in the RPF tables for *all* customer interfaces, 
then the enhanced FP uRPF still works for this scenario.

Sriram 

________________________________________
From: Job Snijders <[email-masked]>
Sent: Tuesday, November 15, 2016 3:26 AM
To: Sriram, Kotikalapudi (Fed)
Cc: Gert Doering; [email-masked]
Subject: Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

ASCII ART:

                +---+
          +-+AS1+--+
          | +---+  |
          |        |
          |        |
        +-+-+    +-+-+
        |AS2|    |AS3|
        +---+-+  +--++
                  |     |
                  |     |
                +-+-+   |
                |AS4+---+
                +---+

Kind regards,

Job

---

From: Brian Dickson <[email-masked]>
Date: Tue, 15 Nov 2016 13:00:32 -0800

Suppose, in the same 4-AS scenario, the following policies:

AS1 receives AS4 prefixes via AS3 only.
AS1 sends a full table to AS3, and a partial table to AS2.
AS2 has a default route pointing to AS1.
AS2 sends its own prefixes to AS4, plus the partial table it receives from
AS1, to AS4.
AS2 DOES NOT HAVE A ROUTE TO AS4
AS2 uses default to reach AS4, via AS3.

AS4 sends traffic to the partial table, via AS2, to AS1.

This is legitimate traffic.

I do not believe FP uRPF, enhanced FP uRPF, or even the further generalized
FP uRPF would handle this.

This is also far from rare, even if it doesn't reach the level of "common
occurrence".

(In particular, it is something that happens A LOT wherever satellite links
are used, where symmetric traffic over the satellite path is actually the
worst possible scenario.)

Brian

On Tue, Nov 15, 2016 at 1:13 AM, Sriram, Kotikalapudi (Fed) <
[email-masked]> wrote:

> Subject: Re: [GROW] Fw: New Version Notification for
> draft-sriram-opsec-urpf-improvements-00.txt
>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 16 Nov 2016 00:17:39 -0500

> (not sure about the "filter" bit, though)

This summarizes my hallway feedback to Sriram.

As noted during mic chat, the existing RPF checks take advantage of existing
line card implementations to do their thing.  The general necessary feature
would be to extend the line cards to take arbitrary lists that may have
nothing to do with the existing FIB contents.

-- Jeff