Community separation control in a closed multi-community node

• US 6,915,351 B2
• Filed: 12/18/2000
• Issued: 07/05/2005
• Est. Priority Date: 12/18/2000
• Status: Active Grant

• Current Assignee: Oracle America, Inc. (Oracle Corporation)
• Original Assignee: Sun Microsystems Incorporated (Oracle Corporation)
• Inventors: Tahan, Thomas E.
• Primary Examiner(s): Etienne, Ario
• Assistant Examiner(s): Osman, Ramy M
• Application Number:
  US09/740,100
• Publication Number:
  US 20020078199A1
• Time in Patent Office: 1,660 Days
• Field of Search: 709/224, 709/225, 709/240, 709/242, 709/249, 709/227, 370/355, 370/389, 370/392, 370/400, 370/395.31, 713/201
• US Class Current: 709/242
• CPC Class Codes: H04L 63/0272 Virtual private networks

Abstract

A method and mechanism of enforcing, in a computer network, a community separation policy wherein the data of a particular user community should be accessible only by members of that community. A Multi-Community Node (MCN) processes information for users in multiple communities and must enforce the community separation policy. In a closed MCN, which runs only applications trusted to enforce the community separation policy, the method and mechanism performs a set of checks on packets received from and to be transmitted on a network, to ensure that all communications comply with the community separation policy. The checks (1) prevent communications from a network used by one community or communities to a network used by different communities; (2) ensure that packets sent by the MCN are output on an interface attached to a network for the intended community; and (3) detect when remote nodes communicating with the MCN spoof their source network address to masquerade as a node in another community. The enforcement method and mechanism use a database of associations of sets of communities corresponding to each network addresses of the MCN and each node with which it communicates, and of the set of communities associated with each network attached to the MCN.

Claims

1. A method of community separation control in a Multi-Community Node (MCN), said method comprising:

ensuring routing table compliance with a community separation policy, wherein all routing table updates are validated to ensure said compliance; and

validating a data packet;

allowing further processing of said data packet in response to detecting said data packet is validated; and

discarding said data packet in response to detecting said data packet is not validated;

wherein said validating said updates comprises;

determining a network interface through which a next hop corresponding to an update of said updates will be reached;

determining whether a first address corresponding to said next hop is within a first address set of said network interface;

discarding said update in response to determining said destination address is not within said first address set; and

performing said update in response to determining said destination address is within said first address set.

2. The method of claim 1, wherein said network interface is said determined by either extracting an identification of said network interface from said update or by finding a network interface whose network address prefix matches that of said next hop.

3. The method of claim 1, wherein said first address is a destination address and said first address set is an Attached Address Set.

4. The method of claim 1, wherein said first address is a Network Address Community Set (NACS) corresponding to a destination address of said next hop, and wherein said first address set is an Interface Community Set (IFCS) of said network interface.

5. The method of claim 1, wherein said data packet is an outgoing data packet, and wherein validating said data packet comprises:

determining said destination address is reachable; and

determining a community set corresponding to an interface over which said data packet is to be output includes a community set corresponding to said destination address.

6. The method of claim 1, wherein said data packet is an incoming data packet, and wherein validating said data packet comprises checking that a source address of said data packet is within an Attached Address Set of the interface over which said data packet was received.

7. The method of claim 1, wherein said data packet is received on a first interface of said MCN and is to be forwarded to a second interface of said MCN, and wherein validating said data packet comprises determining an intersection of an Interface Community Set (IFCS) of said first interface with an IFCS of said second interface is not null.

8. The method of claim 1 further comprising consulting a Community Information Base (CIB).

9. The method of claim 8, wherein said CIB includes an IFCS corresponding to each interface of said MCN, and an Attached Address Set corresponding to each interface of said MCN indicating destination addresses or destination subnets which are reachable through each of said interfaces.

10. The method of claim 1, further comprising recording an event corresponding to said update in response to determining said destination address is not within said first address set.

11. A multi-community node comprising:

a processing unit, wherein said processing unit is configured to ensure routing table compliance with a community separation policy, wherein all routing table updates are validated to ensure said compliance, validate a data packet, allow further processing of said data packet in response to detecting said data packet is validated, and discard said data packet in response to detecting said data packet is not validated; and

a community information base (CIB) coupled to said processing unit;

wherein in validating said updates said processing unit is configured to;

determine a network interface through which a next hop corresponding to an update of said updates will be reached;

determine whether a first address corresponding to said next hop is within a first address set of said network interface;

discard said update in response to determining said destination address is not within said first address set; and

perform said update in response to determining said destination address is within said first address set.

12. The node of claim 11, wherein said network interface is said determined by either extracting an identification of said network interface from said update or by finding a network interface whose network address prefix matches that of said next hop.

13. The node of claim 11, wherein said first address is a destination address and said first address set is an Attached Address Set.

14. The node of claim 11, wherein said first address is a Network Address Community Set (NACS) corresponding to a destination address of said next hop, and wherein said first address set is an Interface Community Set (IFCS) of said network interface.

15. The node of claim 11, wherein said data packet is an outgoing data packet, and wherein in validating said data packet said processing unit is configured to:

determine said destination address is reachable; and

determine a community set corresponding to an interface over which said data packet is to be output includes a community set corresponding to said destination address.

16. The node of claim 11, wherein said data packet is an incoming data packet, and wherein validating said data packet comprises checking that a source address of said data packet is within an AAS of the interface over which said data packet was received.

17. The node of claim 11, wherein said data packet is received on a first interface of said MCN and is to be forwarded to a second interface of said MCN, and wherein validating said data packet comprises determining an intersection of an Interface Community Set (IFCS) of said first interface with an IFCS of said second interface is not null.

18. The node of claim 11 further comprising consulting said CIB.

19. The node of claim 18 wherein said CIB includes an IFCS corresponding to each interface of said MCN, and an AAS corresponding to each interface of said MCN indicating destination addresses or destination subnets which are reachable through each of said interfaces.

20. The node of claim 11, further comprising recording an event corresponding to said update in response to determining said destination address is not within said first address set.

21. A computer network comprising:

a multi-community node (MCN), wherein said node comprises;

a processing unit, wherein said processing unit is configured to ensure routing table compliance with a community separation policy, wherein all routing table updates are validated to ensure said compliance, validate a data packet, allow further processing of said data packet in response to detecting said data packet is validated, and discard said data packet in response to detecting said data packet is not validated; and

a community information base (CIB) coupled to said processing unit;

a first computer network coupled to said MCN; and

a second computer network coupled to said MCN;

wherein in validating said updates said node is configured to;

determine a network interface through which a next hop corresponding to an update of said updates will be reached;

determine whether a first address corresponding to said next hop is within a first address set of said network interface;

discard said update in response to determining said destination address is not within said first address set; and

perform said update in response to determining said destination address is within said first address set.

22. The computer network of claim 21, wherein said node is configured to determine said network interface by either extracting an identification of said network interface from said update or by finding a network interface whose network address prefix matches that of said next hop.

23. The computer network of claim 21, wherein said first address is a destination address and said first address set is an Attached Address Set.

24. The computer network of claim 21, wherein said first address is a Network Address Community Set (NACS) corresponding to a destination address of said next hop, and wherein said first address set is an Interface Community Set (IFCS) of said network interface.

25. The computer network of claim 21, wherein said data packet is an outgoing data packet originating in said MCN, and wherein in validating said data packet said node is configured to:

determine said destination address is reachable; and

determine a community set corresponding to an interface over which said data packet is to be output includes a community set corresponding to said destination address.

26. The computer network of claim 21, wherein said data packet is an incoming data packet from said first computer network, and wherein validating said data packet comprises checking that a source address of said data packet is within an AAS of the interface over which said data packet was received.

27. The computer network of claim 21, wherein said data packet is received on a first interface of said MCN and is to be forwarded to a second interface of said MCN, wherein said first interface corresponds to said first computer network and said second interface corresponds to said second computer network, and wherein in validating said data packet said node is configured to determine that an intersection of an Interface Community Set (IFCS) of said first interface with an IFCS of said second interface is not null.

28. The computer network of claim 21, further comprising consulting said CIB.

29. The computer network of claim 28, wherein said CIB includes an IFCS corresponding to each interface of said MCN, and an AAS corresponding to each interface of said MCN indicating destination addresses or destination subnets which are reachable through each of said interfaces.

30. The computer network of claim 21, further comprising recording an event corresponding to said update in response to determining said destination address is not within said first address set.