On (2015-02-02 11:19 +1300), Nathan Ward wrote:
Hey Nathan,
> This thread was dug up this morning, and I saw this post had gone unanswered.
> There are some curious statements here that I’d like to understand in more
> detail. I've commented inline.i
My pleasure.
> > 1) it does not enforce destination address - this allows FW filter
> > bypass in typical L3 MPLS VPN scenario
>
> Can you run through the exact scenario in which this would be a problem? Are
> you suggesting that a packet can get past the RE protection filter in an
> L3VPN scenario if it’s addressed for a interface in another routing-instance
> or something?
>
> If that’s the case, it won’t even try to go to the RE, so this filter is
> irrelevant. Remember of course that this filter is only going to evaluate
> packets that are going to the control plane, it is never going to see packets
> transiting the router or anything.
Consider customer in their L3 MPLS VPN advertise your NMS network and then
does SSH to PE router linknetwork.
If you only verify source address in FW-filter, customer is allowed to SSH in.
If you also verify destination address in FW-filter, customer is not allowed
in, as you don't punch in your loopback networks in customer links.
One argument might be 'you must stop customer from announcing prefix XYZ', but
is it realistic to guarantee that this is true for all vrfs in whole network?
If one is not updated, whole network is compromised. Much more realistic to
just verify daddr in router.
> > 2) it uses 'from port X' - this allows bgp speakers to connect to any
> > port on your router
>
> 2 things here -
>
> 1) I think you misunderstand how Juniper filters work. “from port” does not
> mean source port, it means if either the source or destination port in the
> packet are 179/BGP then match. Juniper has source-port or destination-port
> statements if you want to get more specific. Of course, if we initiate an
> outbound TCP session, the dest port will be 179/BGP, and the source will be
> an ephemeral port.
>
> 2) BGP only listens on port 179, so, sure they can *try* to talk to another
> port, but that would be pointless. The RE would send RST back, just like any
> other host you try hit on a port that’s not open.
>
> There are two filters provided - router-protect and router-protect-hardcore.
> If you use the -hardcore variant, it drops all messages, so achieves your
> goal - the bgp packets attempting to hit other ports don’t get to the RE.
You have:
term 2 {
from {
source-prefix-list {
bgp-connect;
}
protocol tcp;
port bgp;
}
then {
accept;
}
}
If I, as BGP customer, set DPORT as BGP, and SPORT as arbitrary port, I am
allowed at that arbitrary SPORT.
> > 3) it does not use DDoS protection - this allows trivial way to
> > congest the control-plane
>
> Please explain what this would look like? DDoS protection would be difficult
> to implement in a simple filter - do you mean flood protection? Seems
> reasonable to me that the user can add that if required, but, this is in
> place in all the except the BGP statement (in the -hardcore filter of course)
> and this is of course not something that you should police.
I mean the new ddos-protection feature under 'system', which is pps based, and
today only way to protect box from control-plane congestion attack.
Say one of your BGP customers has L2 loop, and they give you 1.48Mpps of BGP
packets, your network is dead.
Not to mention non-IP frames, which lo0 cannot protect from.
(One reason not to use FXP, is that you can't even protect from this scenario)
> > I didn't review other parts of the suggestion
>
> You should, and you should provide feedback if you feel there are changes.
> The document is of course now 10 years old, and from memory doesn’t make any
> recommendations around IPv6. Team CYMRU are good people, and they regularly
> (or at least, they used to, I assume they still do) get out in to the
> Internet community to run courses at conferences etc. etc. largely at their
> cost.
>
> This is very much just a template, you’ll note that there is a comment at the
> top of the -hardcore filter stating that plenty of protocols haven't been
> considered. For starters, DNS is one that would annoy me here.
Perhaps we should have community driven BCP git repo somewhere for junos, ios,
ios-xr, vrp, timos. So contribution would be essentially merge/pull request.
--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
