Why ISP's deploy RR in BGP core design and what can be done to ensure traffic patterns never traverse the RR router?
BGP requires that all iBGP speakers be fully meshed. However, this requirement does not scale well when there are many iBGP speakers. Instead of configuring a confederation, you can reduce the iBGP mesh by using a route reflector configuration.
A route reflector is a BGP router that is allowed to break the iBGP loop avoidance rule. Route reflectors can advertise updates received from an iBGP peer to another iBGP peer under specific conditions.
By breaking the rules, route reflectors are used to eliminate the full mesh requirement and allow for building iBGP networks that scale easily and cleanly.
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/200153-BGP-Route-Reflection-and-Multiple-Cluste.html
RR is deployed to reduce the number of IBGP connections among IBGP routers in one AS. RR design is much more simpler to configure compared to BGP confederation.
http://packetpushers.net/bgp-rr-design-part-2/
http://packetpushers.net/bgp-rr-design-part-1/
Related
I used to see Cisco's approach when configure BGP:
router bgp 64511
network 101.10.0.0 mask 255.255.255.0
...
ip route 101.10.0.0 255.255.255.0 null0
that is, I need to add the network to routing table so I can advertise it.
Now I need to configure FRR routing suite which mostly mimics the Cisco's config language, and I really doubt if I should (or shouldn't ) add the line route ... null0.
The idea behind adding the line is that Cisco used to require that, idea behind not adding is that Linux (which is underline layer) won't be happy to see extra subnet in its routing table.
Please advice!
(Sorry if I misplace the question, not aware where network questions should go to).
Any routing protocol is working this way: it is sharing routes from it's own routing table to the next hop. You don't need to add route to the Null0 (route to nowhere) if you already have it in your routing table (got it from other hop or it is configured for another interface).
Route to the Null at the example used to add it to the local routing table of the device.
BTW using route to the Null0 is good way if you want to summarize you networks and advertise only this one big network instead of lot of small networks. Routing still be working (because small network have highter priority) and if you will get packets to the host to non existing network it will just drop it by rule => Null0.
I have a Client and Server programs communicating on TCP, implementing IEC-60870-5-104 protocol on the application layer. I am sniffing a copy of all traffic between them,
How do I exactly replicate the IP and TCP layer functionalities on packets sniffed from libpcap in C ?. like IP-reassembly, Managing out-of-order segments, re-transmission, and duplicate TCP segments and separating PDUs, such that I get the same packet as if I was sniffing on the application layer at the Server. (Also please suggest any Frame-works which helps to do this).
This is a very difficult and involved task. It's what network intrusion detection / deep packet inspection systems do and AFAIK there is no drop-in library that handles it.
Your best bet is to build on an existing system such as Bro or Suricata (or maybe wireshark internals) that is already doing the session tracking, state management, re-assembly, re-ordering, duplicate detection, etc. You can then add your own application layer decoding to operate on the re-assembled data stream provided.
Let's say my application has listening UDP socket and it knows from what IP addresses it could receive UDP datagrams. Anything coming from other IP addresses would be considered as malicious datagram and should be discarded as early as possible to prevent DoS attacks. The hard part is that the set of these legit IP addresses can dynamically change over application's life time (ie by dynamically receiving them over control channel).
How would you implement filtering based on the source IP address in the case above?
I see two solutions where to put this source IP filtering logic:
Implement it in the application itself after recvfrom() call.
Install default drop policy in the Firewall and then let the application install Firewall rules that would dynamically whitelist legit IP addresses.
There are pros and cons for each solutions. Some that come to my mind:
iptables could end up with O(n) filtering complexity (con for iptables)
iptables drop packets before they even get to the socket buffer (pro for iptables)
iptables might not be very portable (con for iptables)
iptables from my application could interfere with other applications that potentially would also install iptables rules (con for iptables)
if my application installs iptables rules then it can potentially become attack vector itself (con for iptables)
Where would you implement source IP filtering and why?
Can you name any Applications that follow convention #2 (Administrator manually installing static Firewall rules does not count)?
My recommendation (with absolutely no authority behind it) is to use iptables to do rate-limiting to dampen any DoS attacks and do the actual filtering inside your application. This will give you the least-bad of both worlds, allowing you to use the performance of iptables to limit DoS throughput as well as the ability to change which addresses are allowed without introducing a potential security hole.
If you do decide to go about it with iptables alone, I would create a new chain to do the application-specific filtering so that the potential for interference is lowered.
Hope this helps.
Hope this link help you
Network layer firewalls or packet filters operate at the TCP/IP protocol stack, not allowing packets to pass through the firewall unless they match the established rule set defined by the administrator or applied by default. Modern firewalls can filter traffic based on many packet attributes such as source IP address, source port, destination IP address or port, or destination service like WWW or FTP. They can filter based on protocols, TTL values, netblock of originator, of the source, and many other attributes.
Application layer firewalls work on the application level of the TCP/IP stack, intercepting all packets travelling to or from an application, dropping unwanted outside traffic from reaching protected machines, without acknowledgment to the sender. The additional inspection criteria can add extra latency to the forwarding of packets to their destination.
Mandatory access control (MAC) filtering or sandboxing protect vulnerable services by allowing or denying access based on the MAC address of specific devices allowed to connect to a specific network.
Proxy servers or services can run on dedicated hardware devices or as software on a general-purpose machine, responding to input packets such as connection requests, while blocking other packets. Abuse of an internal system would not necessarily cause a security breach, although methods such as IP spoofing could transmit packets to a target network.
Network address translation (NAT) functionality allows hiding the IP addresses of protected devices by numbering them with addresses in the "private address range", as defined in RFC 1918. This functionality offers a defence against network reconnaissance
I have created an P2P application which is FULLY decentralized and is using a Kademlia algorithm to make it so. This has been tested on the local network and it completely successful.
I heard about UDP Hole Punching, however hole punching requires the peer to know about the clients IP and vice versa, however as said due to design it is impossible. As it would require each peer to keep on asking the supernode\server for new arrivals and keep them assigned and so naturally it is not too dependable especially if the supernode is down.
Due to the design of the algorithm 1 peer does not know the other peers IP address so I need 1 peer to completely open a port up for PUBLIC to be able to connect to, how can I do this, in Windows? could someone perhaps also give me suitable links that might give me a direction?
It would be preferable (but not absolute) if they use c++\c as example
I think you will have to change your architecture a little. There is no other way for NAT traversal unless you configure your NAT for port forwarding (I think you don't want this). You might need to implement three layers:
Lower layer 1: it knows about IP addresses and ports and can solve problems like hole punching or dealing with servers (which could be down but first you have no choice and second you can add alternatives for connectivity).
Layer 2: implements special naming, addressing and location services for your solution (instead of using IP addresses).
Upper layer 3: implements your p2p solution using lower layer naming and location services.
First of all, you need to examine your design. If it needs 100% connectivity between all nodes (without relays) it's probably going to fail under IPv4 since not all NATs are traversable. And possibly under IPv6 due to stateful firewalls.
Now, for the nat traversal: A solution for DHT-assisted NAT traversal is for NATed nodes to have a rendezvous node.
To keep the UDP NAT mappings open it has to regularly ping that rendezvous node.
Additionally it has to announce the address of the rendezvous point on the DHT, e.g. under hash("rendezvous" + node ID) or simply on its reachable neighbor nodes.
The rendezvous node can then act as coordination point for hole punching.
This does not require any special "supernode", just other (possibly multiple, thus eliminating the SPOF) nodes in the network that are not NATed and can assist.
Additional mechanisms such as UPnP IGP, NAT-PMP, PCP and ultimately instructing users to forward the needed ports can also help to reduce the need for nat traversal.
Due to the design of the algorithm 1 peer does not know the other peers IP address so I need 1 peer to completely open a port up for PUBLIC to be able to connect to
First of all this will only work for Full cone NAT. For other types of NAT that public IP:Port you open will only work for specific destination. In your case you don't know the destination so it's impossible.
In case of full cone NAT, you send a packet to a random address with low TTL value so that the packet drops in the middle and doesn't reach that address. If it reaches than that address's NAT might block you. If you do this then a port will be opened for anybody to send you a packet. You need to keep sending packets after some short interval for that port to be remained open. Here is a problem that you can't choose which port to open in the NAT. The NAT will assign you a free port on its own.
Finally I don't see any point doing any of the above if peers can't exchange their IP information with each other. You should use a signalling protocol like SIP or XMPP to exchange IP information between peers.
To learn more about NATs please read this answer.
In BitTorrent, client connects to the tracker specified in .torrent file. Tracker is a kind of centralized server and it is the starting point. So BitTorrent is not pure p2p.
If we want to develop pure p2p system, we should design routing overlay network. All nodes will have routing table like routers do. But even in routing overlay network, each node should know at least one existing node(GUID, IP address) initially. So how can we determine this? Should we keep 'one existing node to connect initially' forever like fixed centralized server? If so, I think this is not fully decentralized method.
The solution you describe (defining a central peer wit well-know ip address) is not the only one.
The other solution is to post an html page (or json file) in a well-know URL on the net, and make sure this item contains an updated list of peers this peer can initialy connect. This list can be updated if a peer goes down. Eventually, you can use multiple URLs.
Pure P2P system is a theoretical concept which cannot be implemented fully in reality.
You could use an anycast. So the first other client will answer and may send such an initial "client list". Where your client can connect to them to get more lists.
Classically I would implement a multicast to a adress and wait for an answer of other clients.
Firstly, a true peer to peer network is not necessarily decentralized. Secondly, decentralization does not necessarily mean that the network doesn't make use of secondary services which may themselves be centralized.
The main question in both of these issues is wheather the primary resources of the network solution are distributed through correlated peers.
For example, peer-to-peer video conferencing may use a central contacts service but still be pure peer-to-peer as long as the peers resolve such issues before entering a true peer-to-peer scope. This would also be decentralized.
What it comes down to is what your trying to solve by using peer-to-peer. A video conference is a video conference - it starts with a video being recorded on one peer and ends with the video being viewed on another. As long as each byte of this data is transferred directly between the peers (even if there's hundreds of peers in the conference, and regardless of how these peers found each other) it is a true peer-to-peer video conference.
Note that the video peers will still be in your typical ring, and that the contacts lists may still use the node key for location information rather than an IP. This will still be a network overlay as it will still be built over IP, replacing it's addressing scheme on the peer level to facilitate true peer-to-peer networking.
What it realy comes down to is the concepts of a network connection. IP just pushes packets to unspecified routers until it gets to a specific address. 'connections' between each endpoint only exist within the higher software levels (including when dealing with TCP/IP). A connection is just the data used within software to understand who is who and how each point can handle data etc. Peer-to-peer network overlays effectively distributes this data, eliminating the need for each peer to create massive amounts of connections to communicate on a massive scope. Decentralization is not required for this (as long as peer to peer communication is not centralized), and a secondary service within the system wont necessarily limit a network's scope or otherwise centralize actual peer-to-peer networking.
So to answer your question, it doesn't matter where it initially connects in order to be considered peer-to-peer, and different peer-to-peer services will handle this based on their service design.
Ok so I am thinking about writing a p2p protocol for a number of different services for an AI project, and I thought I'd come here to see if i could get some ideas on how to get the initial connection.
I have come across several ways to establish the initial connection:
1) You have a static ip address on the internet that distributes information on other peers. This isn't good, because:
a) it's a single point of failure, the service could go offline, preventing any new connections from creating an initial connection to peers,
b) the IP address could change. This could be mitigated by using a domain name which is maintained to point to the current ip address of the location of a service which provides data on peers, however this can be subverted in theory by hackers by spoofing or arp poisoning, dns attacks etc.
2) You could force the user to provide an initial ip address or hostname for another peer, and it's up to the user to find the hostname / ip address / port number. This is good, but if someone posts disinformation or they cannot find a peer on google or some other search site then obviously it's fallable.
3) You could leave it to the peer to publish their own existence in a central location - for example a group of IRC channels or a group of websites. Again, unless it's going through a central trusted domain, it's hard to determine the authenticity of the peer.
4) You could use some kind of nmap style discovery algorithm that searches through subnets for appropriate protocols. The problem with this approach is it's slow and it's likely to attract attention from things like firewalls etc.
5) This is a variation of 3) you could allow the peers to advertise their own information on a website, then instead of having to look for the information in a suitable location (a specific website, or group of websites), you can let google's search algorithm find it, and do the discovery for you, however you could imagine that this may take a few days for google to cache the website data with information on the peers. Also again, it would be upto you to provide some way to verify the authenticity of the advertised data.
6) If you are interested in an exclusive p2p network that locks out certain people (for example, you might want to have a file sharing network and you don't want law enforcement to be able to access it, or MPIAA), then you could use 2) and then have a referral system where you require that the initial connection provide the referrer's ip address, and then the service could connect to the referrers ip address and ask the referrer if they did indeed refer the referee.
That's all I can think of currently, but if anyone comes up with any other ways to do this, i would be very interested.