Re: DHCPv6-PD relay route injection - standard?

[Mikael Abrahamsson]

On Sun, 19 May 2019, Brandon Martin wrote:

I guess my impression from RFC8415 was that it was up to the network 
administrator and their equipment vendor to resolve this.  Certainly, I 
wouldn't have expected automatic route injection, though having such a


There needs to be interaction between the packet forwarding layer and the 
DHCP layer when doing things like DHCPv6-PD, otherwise it's not of any 
use.


Another thing that will be in this document is that we've observed quite a 
few gotchas that aren't obvious, and for different deployment scenarios 
you want things handled differently by the relay.


One example:

What do you do when you have an active lease and the same DUID shows up on 
another interface, requesting a prefix? If you're a wireline operator then 
you most likely want to hand out a different prefix, because this is now 
two different customers and you want to treat them as two different 
clients even if they happen to have the same MAC address and DUID.


If you're instead an enterprise for instance, and you want to support 
devices moving around and having their PD follow them, then you want to 
the opposite, you instead want to just treat it as the same client that 
now moved.


Back in 2005 I was involved in an wireline deployment, and I checked the 
customer mac addresses. 5% of the customers had the same mac address 
visible to us. Seems a very popular electronics store router vendor had 
shipped all their routers of a certain model with the same MAC address as 
its default address. I was happy I had designed the wireline solution with 
one vlan per customer so this wasn't a problem. Other ISPs weren't so 
fortunate and had to spend significant customer support time/money helping 
customers use the "clone PC MAC address" functionality in the HGW to work 
around this problem.


In DHCPv6 the DUID is considered "world unique", but as wel all know who 
work in operational environment, the world typically doesn't adhere to 
strict rules.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: DHCPv6-PD relay route injection - standard?

[Brandon Martin]

On 5/18/19 4:45 AM, Mikael Abrahamsson wrote:
> The area of how the router on the LAN gets the DHCPv6-PD route injected never 
> was standardized because consensus couldn't be reached on how to do it, so it 
> was glossed over and vendors solved it the way they saw fit. I've seen 
> implementations where no route was injected (to customer astonishment of 
> course becase it's useless without this), so this is functionality that needs 
> at least some kind of specification.

I'll keep my eye out for it.

I guess my impression from RFC8415 was that it was up to the network 
administrator and their equipment vendor to resolve this.  Certainly, I 
wouldn't have expected automatic route injection, though having such a feature 
available is of course really nice.  Some sort of standard behavior for it is 
preferable if it's going to be implemented.

My punt in the absence of support for it on my platform (I'm arguing to get it 
implemented) was to inject the route via BGP from the DHCP lease database.  
That's very flexible, but it's also a heck of a lot more work of course.
-- 
Brandon Martin

Re: BGP prefix filter list

[Alejandro Acosta]

Hello Amir,

On 5/18/19 1:08 PM, Amir Herzberg wrote:
This discussion is very interesting, I didn't know about this problem, 
it has implications to our work on routing security, thanks!


Your welcome..., since long time ago I wanted to expose our findings in 
English.





On Sat, May 18, 2019 at 11:37 AM Alejandro Acosta 
> wrote:



   If you learn, let's say, up to /22 (v4), and someone hijacks
one /21
you will learn the legitimate prefix and the hijacked prefix. Now,
the
owner of the legitimate prefix wants to defends their routes
announcing
/23 or /24, of course those prefixes won't be learnt if they are
filtered.


I wonder if this really is a consideration to avoid filtering small 
prefixes (e.g. /24):



My position is exactly the opposite.




- attackers are quite likely to  do sub-prefix hijacks (or say a 
specific /24), so I'm not sure this `hits' defenders more than it 
`hits' attackers



Yes, you are right, but anyhow -IMHO- this still better than not 
learning small prefixes at all.



- I think we're talking only/mostly about small providers here, right? 
as larger providers probably will not have such problems of tables 
exceeding router resources.I expect such small providers normally 
connect thru several tier-2 or so providers... if these upper-tier 
providers get hijacked, the fact you've prevented this at the 
stub/multihome ISP may not help much - we showed how this happens with 
ROV in our NDSS paper on it:
https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/are-we-there-yet-rpkis-deployment-and-security/ 




You are right here.

Thanks for the link, I will take a look.


Alejandro,




Amir Herzberg
Comcast professor for security innovation
Dept. of Computer Science and Engineering, University of Connecticut

Foundations of Cybersecurity: 
https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security


Homepage: https://sites.google.com/site/amirherzberg/home

Re: BGP prefix filter list

[Amir Herzberg]

This discussion is very interesting, I didn't know about this problem, it
has implications to our work on routing security, thanks!

On Sat, May 18, 2019 at 11:37 AM Alejandro Acosta <
alejandroacostaal...@gmail.com> wrote:

>
>If you learn, let's say, up to /22 (v4), and someone hijacks one /21
> you will learn the legitimate prefix and the hijacked prefix. Now, the
> owner of the legitimate prefix wants to defends their routes announcing
> /23 or /24, of course those prefixes won't be learnt if they are filtered.
>

I wonder if this really is a consideration to avoid filtering small
prefixes (e.g. /24):

- attackers are quite likely to  do sub-prefix hijacks (or say a specific
/24), so I'm not sure this `hits' defenders more than it `hits' attackers
- I think we're talking only/mostly about small providers here, right? as
larger providers probably will not have such problems of tables exceeding
router resources.I expect such small providers normally connect thru
several tier-2 or so providers... if these upper-tier providers get
hijacked, the fact you've prevented this at the stub/multihome ISP may not
help much - we showed how this happens with ROV in our NDSS paper on it:
https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/are-we-there-yet-rpkis-deployment-and-security/




Amir Herzberg
Comcast professor for security innovation
Dept. of Computer Science and Engineering, University of Connecticut

Foundations of Cybersecurity:
https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber-Security

Homepage: https://sites.google.com/site/amirherzberg/home

Re: Free Program to take netflow

[Joe Loiacono]

Dennis,

You might try FlowViewer https://sourceforge.net/projects/flowviewer

Fairly easy Linux install over top of SiLK, netflow capture and analysis 
software from Carnegie-Mellon. SiLK is very robust and FlowViewer 
provides a web-based interface with extensive analysis, graphing and 
tracking tools. Filtering includes by AS. You can create an MRTG-like 
set of long-term graphs for each AS and as a group of top 10 ASes (Last 
24 Hours, 7 Days, 4 Weeks, 3 Years.)


Best,

Joe

On 5/17/2019 10:26 AM, Dennis Burgess via NANOG wrote:


I am looking for a free program to take netflow and output what the 
top traffic ASes to and from my AS are.   Something that we can look 
at every once in a while, and/or spin up and get data then shutdown..  
Just have two ports need netflow from currently.


Thanks in advance.

*LTI-Full_175px*

*Dennis Burgess, Mikrotik Certified Trainer *

Author of "Learn RouterOS- Second Edition”

*Link Technologies, Inc*-- Mikrotik & WISP Support Services

*Office*: 314-735-0270 Website: http://www.linktechs.net 



Create Wireless Coverage’s with www.towercoverage.com

Re: BGP prefix filter list

[Alejandro Acosta]

Hello,

   As a comment, after receiving several complains and after looking 
many cases, we evaluated what is better, to cut the table size filtering 
"big" network or "small" networks.  Of course this is a difficult 
scenario and I guess there are mix thinking about this, however, we 
concluded that the people (networks) that is less affected are those who 
learn small network prefixes (such as /24, /23, /22, /21 in the v4 world).


  If you learn, let's say, up to /22 (v4), and someone hijacks one /21 
you will learn the legitimate prefix and the hijacked prefix. Now, the 
owner of the legitimate prefix wants to defends their routes announcing 
/23 or /24, of course those prefixes won't be learnt if they are filtered.


  We published this some time ago (sorry, in Spanish): 
http://w4.labs.lacnic.net/site/BGP-network-size-filters



That's it, my two cents.


Alejandro,



On 5/15/19 7:43 AM, Baldur Norddahl wrote:

Hello

This morning we apparently had a problem with our routers not handling 
the full table. So I am looking into culling the least useful prefixes 
from our tables. I can hardly be the first one to take on that kind of 
project, and I am wondering if there is a ready made prefix list or 
similar?


Or maybe we have a list of worst offenders? I am looking for ASN that 
announces a lot of unnecessary /24 prefixes and which happens to be 
far away from us? I would filter those to something like /20 and then 
just have a default route to catch all.


Thanks,

Baldur

Re: DHCPv6-PD relay route injection - standard?

[Brandon Martin]

On 5/18/19 4:44 AM, Radu-Adrian Feurdean wrote:

That one seems to be the simpler form, depending only on an external DHCP 
server. It may be enough for some set-ups. Subscriber functionality provides 
more options, such as enforcing auth and internal dhcp server that takes data 
to be returned from RADIUS. It also allows dissociation between L2 and L3 (same 
subnet on several VLANs).

You can almost call it SDN:)  


It's perfect for lots of smaller networks that have L2 DHCP snooping and 
access enforcement via that means.  My L2 happens to offer just that.  I 
do have to enforce a somewhat "traditional" L2-L3 mapping, but it works 
fine on this network, at least.

--
Brandon Martin

Re: BGP prefix filter list

[Baldur Norddahl]

On Fri, May 17, 2019 at 10:43 PM Blake Hudson  wrote:


> I manage a network like you describe: Two BGP edge routers, both routers
> accept a full eBGP feed from transit, both share routing information via
> iBGP. Both edge routers in my network have a complete view. If one transit
> provider is down or there is an upstream peering change, both still have a
> complete view. The only time they wouldn't have a complete view is during
> convergence or when there is a simultaneous outage of both transit
> providers at different physical facilities.
>
>
What I mean by not having a complete view, is that your two routers do not
have the same information. One router has all the routes from the transit
directly connected, but only a subset of routes from the other transit
provider. And visa versa for the other router. Therefore the two routers
might not make the same routing decisions.

Let me show you an example from two routers in our network:

albertslund-edge1#show bgp vpnv4 unicast vrf internet detail 8.8.8.0
255.255.255.0
BGP routing table entry for 8.8.8.0/24
20w0d received from 193.239.117.141 (66.249.94.118), path-id 0
   Origin i, nexthop 193.239.117.141, metric 100, localpref 500,weight 0,
rtpref 200, best, block best, selected,
   Community 60876:34307
   As path [15169]
   As4 path
   Received label  notag

Imported from 185.24.168.254 (185.24.168.254); Route Distinguisher:60876:0
(default for vrf internet)
   Origin i, nexthop 185.24.168.254, metric 100, localpref 500,weight 0,
rtpref 200,
   Community 60876:34307
   As path [15169]
   As4 path
   Route target:60876:0
   Received label  164540

---

ballerup-edge1#show bgp vpnv4 unicast vrf internet detail 8.8.8.0
255.255.255.0
BGP routing table entry for 8.8.8.0/24
43w1d received from 193.239.117.141 (66.249.94.118), path-id 0
   Origin i, nexthop 193.239.117.141, metric 100, localpref 500,weight 0,
rtpref 200, best, block best, selected,
   Community 60876:34307
   As path [15169]
   As4 path
   Received label  notag

Imported from 185.24.171.254 (185.24.171.254); Route Distinguisher:60876:0
(default for vrf internet)
   Origin i, nexthop 185.24.171.254, metric 100, localpref 500,weight 0,
rtpref 200,
   Community 60876:34307
   As path [15169]
   As4 path
   Route target:60876:0
   Received label  164140

29w2d received from 216.66.83.101 (216.218.252.202), path-id 0
   Origin i, nexthop 216.66.83.101, metric 100, localpref 450,weight 0,
rtpref 200,
   Community 60876:6939
   As path [6939 15169]
   As4 path
   Received label  notag

43w2d received from 149.6.137.57 (154.26.32.142), path-id 0
   Origin i, nexthop 149.6.137.57, metric 200, localpref 100,weight 0,
rtpref 200,
   Community 174:21100 174:22010 60876:174
   As path [174 6453 15169]
   As4 path
   Received label  notag

---

One router knows about 2 paths, the other about 4 paths. Why? Because BGP
only advertises the route that is in use. Everyone here of course knows
this, I am just pointing it out because culling information before allowing
it to be redistributed within your network is what BGP is already doing
anyway. It is possible to remove some of that information from the local
FIB too without losing anything at all.

Using a default also gives you a dramatically shorter convergence time if
one of the transits goes down. Having 800k routes can be harmful to your
network even with equipment that can handle it. Yes I am aware that I am
not doing what I am preaching here, but I am considering it :-).

Regards

Baldur

Re: DHCPv6-PD relay route injection - standard?

[Mikael Abrahamsson]

On Tue, 14 May 2019, Brandon Martin wrote:

Is there a standard that defines/recommends behavior for route injection of 
snooped DHCPv6-PD (or IA, I guess) assignments on routers running relay 
agents?


No, there isn't. However, there is now work ongoing work in the IETF to at 
least create a functional description of one.


I read a pre-version of the -00 yesterday (my colleague is one of the 
authors), hopefully a first version of it should be posted coming week. 
Check out the IETF WG mailing list for when it's posted.


The area of how the router on the LAN gets the DHCPv6-PD route injected 
never was standardized because consensus couldn't be reached on how to do 
it, so it was glossed over and vendors solved it the way they saw fit. 
I've seen implementations where no route was injected (to customer 
astonishment of course becase it's useless without this), so this is 
functionality that needs at least some kind of specification.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: DHCPv6-PD relay route injection - standard?

[Radu-Adrian Feurdean]

On Sat, May 18, 2019, at 09:52, Brandon Martin wrote:

> What it does is hook into the DHCPv6 lightweight relay functionality. 
> Basically, it just snoops the DHCPv6 replies for a PD assignment and 
> inserts a quasi-static route into its table for anything that it sees 
> with next-hop pointing at wherever the reply was going.  The static 
> route is time-limited and gets removed when the delegation expires (or 
> presumably if it sees a release of the corresponding resources).  It 
> stores the database of those learned delegations, including expiry, in 

Yep, that's exactly the expected behaviour (or at least a big part of it)... 
providedit's implemented properly. 

> persistent memory so that it can re-install them in event of a reload. 

That's an interesting point, most subscriber management implementations don't 
implement this, requiring low dhcp timers. 

> The key here is that it doesn't care about "who" is getting the 
> resources or why.  All it cares is that it saw a DHCPv6 reply via its 
> relay that included a delegated prefix.

Exactly, that's dhcp server's job. Or at least that's what I do at $job[$now]. 

> Juniper, at least, and presumably Cisco too, also implement a means to 
> get that information via RADIUS.  That may be more what you're thinking of?

That's "subscriber management". On Cisco (A9K and A1K) and NokiALU (SR 7750) 
you normally need a license, even if it's (for now) honor-based. On Cisco 
it'the "broadband"/BNG, on NokiALU it's "xK subscribers". 

> I'm not sure that the Cisco implementation I'm thinking of requires the 
> BNG/BRAS features to be licensed.  See [1] under heading "DHCPv6 Relay 
> Agent Notification for Prefix Delegation".  In particular, note:

That one seems to be the simpler form, depending only on an external DHCP 
server. It may be enough for some set-ups. Subscriber functionality provides 
more options, such as enforcing auth and internal dhcp server that takes data 
to be returned from RADIUS. It also allows dissociation between L2 and L3 (same 
subnet on several VLANs). 

You can almost call it SDN :) 

Re: DHCPv6-PD relay route injection - standard?

[Brandon Martin]

On 5/18/19 2:33 AM, Radu-Adrian Feurdean wrote:

Those being said, I'm interested in how that feature is supported on gear that is not 
"subscriber-aware" (you were talking about Arista), since generating routing information 
from relayed DHCP(v6) is a big/important part of the "subscriber management" 
functionality.


What it does is hook into the DHCPv6 lightweight relay functionality. 
Basically, it just snoops the DHCPv6 replies for a PD assignment and 
inserts a quasi-static route into its table for anything that it sees 
with next-hop pointing at wherever the reply was going.  The static 
route is time-limited and gets removed when the delegation expires (or 
presumably if it sees a release of the corresponding resources).  It 
stores the database of those learned delegations, including expiry, in 
persistent memory so that it can re-install them in event of a reload. 
Obviously having good reltime information on the router is important for 
this.


The key here is that it doesn't care about "who" is getting the 
resources or why.  All it cares is that it saw a DHCPv6 reply via its 
relay that included a delegated prefix.


Juniper, at least, and presumably Cisco too, also implement a means to 
get that information via RADIUS.  That may be more what you're thinking of?


I'm not sure that the Cisco implementation I'm thinking of requires the 
BNG/BRAS features to be licensed.  See [1] under heading "DHCPv6 Relay 
Agent Notification for Prefix Delegation".  In particular, note:



No user configuration is required for this feature. Static route management is 
done automatically by the relay agent.


It sounds like it operates similar to how I described above.  Basically, 
you can relegate your "subscriber management" to simple DHCP if such a 
lightweight implementation is sufficient for your needs.


-

[1] 
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configuration/xe-3s/dhcp-xe-3s-book/ip6-dhcp-rel-agent-xe.pdf

--
Brandon Martin