Routing

 View Only
last person joined: yesterday 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  root reflector security

    Posted 27 days ago

    hi guys.

    in our company we have a MPLS backbone with 70 nodes ( MX 204, MX 10003 and 10008) router.

    We are currently usin 4 MX 10003 routers as a root reflector cluster.

    No, we want so secure the ruster to make it 

    Now we want to secure the cluster with encryption.

    Now my question.

    Can i do it this way so that the old an the new both work an exchange the routes each other?

    Thanks fo your helb...



  • 2.  RE: root reflector security

    Posted 22 days ago
    Doesn't anyone here have an idea, or doesn't anyone want to answer?



  • 3.  RE: root reflector security

     
    Posted 21 days ago

    Hi Thomas,

    Just read your message but I'm trying to understand what you are trying to achieve here. Typically a route reflector is inside your own network, so I'm not entirely sure what purpose the encryption would serve. If traffic were to flow across external connectivity it makes sense I suppose, as you might not want others to read your data, but the BGP route information typically isn't all that big of a concern, but I do not know your network or customers, so I don't mean this as passing judgement on the choice.

    There are of course ways to secure your sessions with authentication options to ensure that the neighbors are only established with verified neighbors and you can't get a MITM for these, such as BGP-MD5 (authentication-key (Protocols BGP and BMP) | Junos OS | Juniper Networks), which is the more legacy approach, or the newer version of using BGP with TCP-AO (TCP Authentication Option (TCP-AO) | Junos OS | Juniper Networks) for a better security level.

    If you do want to further enhance it with encryption then I suppose you'll need to utilize IPsec for your BGP traffic, this is elaborated on this page:

    IP Security for BGP | Junos OS | Juniper Networks

    As encryption is inherently a 2-way street though it will not be such that it can support both the old and new way unless you set up an entirely new session in parallel with the existing one (you'd need a separate loopback IP on your route reflectors as well as all your other routers, as you can't configure 2 BGP sessions with the same neighbor IP)

    Note that I do not have personal experience with this setup though, we do not utilize BGP encryption inside our network since we operate our own backbone and have full control over the end-to-end path, and quite frankly I do not see a realistic scenario where someone could intercept that traffic in-flight without that being noticable (nor do I see a likely scenario where they could do anything useful with that data if they did). This is not discrediting your usecase of course, as I do not know how your network looks or what kind of traffic is on there, merely relaying our own considerations for this choice for reflection :)




  • 4.  RE: root reflector security

    Posted 20 days ago

    Thanks for your answer of my question.

    I will shortly explain, why we wan to secure our bgb roote reflector.

    Wer operate like you our own backbone and we have like youl full controll over the end-to-ens paths between the mpls router.

    The idea, to secure the root reflector comes from a service engeneer from Juniper Networks.

    His idea was, that no stranger router can manipulate our root table.

    And i understand , that when we want to secure, we should use ipvsec.

    THX for all.

    Thomas




  • 5.  RE: root reflector security

    Posted 19 days ago

    Securing your IGP is great.

    Securing your iBGP, no that much.

    First BGP is a protocol using TCP (so you already have the TCP segment numbers protecting somewhat introducing stuff in the flow).

    Second, in my experience, I've seen catastrophic failures and collapses on some backbones in the past while trying to introduce TCP MD5 in iBGP, because of additional CPU constraints due to it (iBGP flows for readvertising routes from the DefaultFreeZone [Internet] are, well, very large, specially when something happens, the router gears already are at 100% CPU when you have some tens of thousands of routes to change/reprogram, and so on).

    So: I've seen such efforts to introduce TCP MD5 in iBGP. It was a complete mess. Yes it was in the past, yes routers have better CPUs today. But it's not needed: you're about to fix a security risk that doesn't exist while introducing an operational risk that has already been observed in the reality.

    Just don't do it.



    ------------------------------
    Olivier Benghozi
    ------------------------------