)]}'
{"doc/source/specs/index.rst":[{"author":{"_account_id":6835,"name":"Kun Huang","email":"gareth@openstacker.org","username":"academicgareth"},"change_message_id":"eeb0aa7c00840a116957444882a80f6fa3f2a28b","unresolved":false,"context_lines":[{"line_number":35,"context_line":"    skeleton"},{"line_number":36,"context_line":"    template"},{"line_number":37,"context_line":"    distributed_dnat"},{"line_number":38,"context_line":"    securitygroup"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Indices and tables"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a7b0d38_fb06491f","line":38,"updated":"2015-12-23 16:33:30.000000000","message":"s/securitygroup/security_group","commit_id":"42cd9afae7f7a30aa13cf4fc9f12a1a896ddd536"}],"doc/source/specs/security_group.rst":[{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"ca1a2e1404ae0420d0410081b8d31fa6fe6caa57","unresolved":false,"context_lines":[{"line_number":1,"context_line":"Security Group"},{"line_number":2,"context_line":""},{"line_number":3,"context_line":"https://blueprints.launchpad.net/dragonflow/+spec/security-group-dragonflow-driver "},{"line_number":4,"context_line":"This blueprint describe how to implement Security Group in Dragonflow."},{"line_number":5,"context_line":""},{"line_number":6,"context_line":"1\tProblem Description"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a710552_2177f603","line":3,"updated":"2015-12-14 18:46:55.000000000","message":"Please convert the structure to fit the spec structure, you can see an example here:\n\nhttps://review.openstack.org/#/c/251116/","commit_id":"05d8a00f1c15a94f3f55d1290f24fcc7038627af"},{"author":{"_account_id":18668,"name":"ding bo","email":"longddropt@163.com","username":"longddropt"},"change_message_id":"1c6ecc460de767388e068a556bd2bcb317dee7c5","unresolved":false,"context_lines":[{"line_number":1,"context_line":"Security Group"},{"line_number":2,"context_line":""},{"line_number":3,"context_line":"https://blueprints.launchpad.net/dragonflow/+spec/security-group-dragonflow-driver "},{"line_number":4,"context_line":"This blueprint describe how to implement Security Group in Dragonflow."},{"line_number":5,"context_line":""},{"line_number":6,"context_line":"1\tProblem Description"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a7e1126_ec5fa073","line":3,"in_reply_to":"5a710552_2177f603","updated":"2015-12-17 06:07:56.000000000","message":"Thanks,I will correct the structure soon","commit_id":"05d8a00f1c15a94f3f55d1290f24fcc7038627af"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"ca1a2e1404ae0420d0410081b8d31fa6fe6caa57","unresolved":false,"context_lines":[{"line_number":4,"context_line":"This blueprint describe how to implement Security Group in Dragonflow."},{"line_number":5,"context_line":""},{"line_number":6,"context_line":"1\tProblem Description"},{"line_number":7,"context_line":"Neutron use iptables to implement security group in current community solution. Because connect tracking is not supported by ovs, one linux bridge is inserted between VM and ovs bridge. However, it introduces unnecessary overhead and latency for traffic forwarding. "},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"As connection tracking is supported in ovs v2.4.0 now, seurity group iptables rules can be translated into openflow tables and installed in ovs bridge to implement traffic security control."},{"line_number":10,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a710552_417482fc","line":7,"updated":"2015-12-14 18:46:55.000000000","message":"Please remove those trailing spaces (they are the red boxes you see on this review)","commit_id":"05d8a00f1c15a94f3f55d1290f24fcc7038627af"},{"author":{"_account_id":18668,"name":"ding bo","email":"longddropt@163.com","username":"longddropt"},"change_message_id":"1c6ecc460de767388e068a556bd2bcb317dee7c5","unresolved":false,"context_lines":[{"line_number":4,"context_line":"This blueprint describe how to implement Security Group in Dragonflow."},{"line_number":5,"context_line":""},{"line_number":6,"context_line":"1\tProblem Description"},{"line_number":7,"context_line":"Neutron use iptables to implement security group in current community solution. Because connect tracking is not supported by ovs, one linux bridge is inserted between VM and ovs bridge. However, it introduces unnecessary overhead and latency for traffic forwarding. "},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"As connection tracking is supported in ovs v2.4.0 now, seurity group iptables rules can be translated into openflow tables and installed in ovs bridge to implement traffic security control."},{"line_number":10,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a7e1126_8c513c65","line":7,"in_reply_to":"5a710552_417482fc","updated":"2015-12-17 06:07:56.000000000","message":"Ok","commit_id":"05d8a00f1c15a94f3f55d1290f24fcc7038627af"},{"author":{"_account_id":7805,"name":"Li Ma","email":"skywalker.nick@gmail.com","username":"Nick"},"change_message_id":"935a61ae2986b23bc2bb011ba8d4a2a8b45486e2","unresolved":false,"context_lines":[{"line_number":26,"context_line":"Ingress security group table provides following features as below, and the flows installed in this table are all proactive way."},{"line_number":27,"context_line":"1)Anti-arp ip spoofing"},{"line_number":28,"context_line":"  When controller has detected the Security Group is assigned to a local port, it install this flow. This flow matches the in_port and the port\u0027s mac and ip pair and passes it to the next table. If doesnot match, it drops the packet."},{"line_number":29,"context_line":"2)Anti-dhcp spoofing"},{"line_number":30,"context_line":"  A vm is never being expected to be a dhcp server, thus must not send dhcp reply messages. In case of it, the controller will install a flow which drops all the dhcp server packets from a vm port, matching fields includeing protocol:udp, scr port:67 and dst port:68. "},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"2.4\tForwading Security Table"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a710552_0bdc35e3","line":29,"updated":"2015-12-15 10:37:54.000000000","message":"It depends. You should let the end-user decide. If you wanna implement it, I suggest you put an option to enable or disable if possible.","commit_id":"05d8a00f1c15a94f3f55d1290f24fcc7038627af"},{"author":{"_account_id":7805,"name":"Li Ma","email":"skywalker.nick@gmail.com","username":"Nick"},"change_message_id":"7e931db8b587f76a9f02f02f4d80bcd69874cb51","unresolved":false,"context_lines":[{"line_number":26,"context_line":"Ingress security group table provides following features as below, and the flows installed in this table are all proactive way."},{"line_number":27,"context_line":"1)Anti-arp ip spoofing"},{"line_number":28,"context_line":"  When controller has detected the Security Group is assigned to a local port, it install this flow. This flow matches the in_port and the port\u0027s mac and ip pair and passes it to the next table. If doesnot match, it drops the packet."},{"line_number":29,"context_line":"2)Anti-dhcp spoofing"},{"line_number":30,"context_line":"  A vm is never being expected to be a dhcp server, thus must not send dhcp reply messages. In case of it, the controller will install a flow which drops all the dhcp server packets from a vm port, matching fields includeing protocol:udp, scr port:67 and dst port:68. "},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"2.4\tForwading Security Table"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a7e1126_ded838f2","line":29,"in_reply_to":"3a7e1126_0c68ecf4","updated":"2015-12-17 08:00:16.000000000","message":"At this stage, it is OK. You assume that IPAM is provided by neutron, but actually I can make it as an external service. Using a VM connected to physical network as a DHCP server to manage all the IP is possible. Even with the help of ToR, a VM which connect to physical network can be a member of a given virtual segment. If it is a DHCP server, it is also possible.","commit_id":"05d8a00f1c15a94f3f55d1290f24fcc7038627af"},{"author":{"_account_id":18668,"name":"ding bo","email":"longddropt@163.com","username":"longddropt"},"change_message_id":"2255df2ddde19f7a34a14b1ded690ac17bd589ab","unresolved":false,"context_lines":[{"line_number":26,"context_line":"Ingress security group table provides following features as below, and the flows installed in this table are all proactive way."},{"line_number":27,"context_line":"1)Anti-arp ip spoofing"},{"line_number":28,"context_line":"  When controller has detected the Security Group is assigned to a local port, it install this flow. This flow matches the in_port and the port\u0027s mac and ip pair and passes it to the next table. If doesnot match, it drops the packet."},{"line_number":29,"context_line":"2)Anti-dhcp spoofing"},{"line_number":30,"context_line":"  A vm is never being expected to be a dhcp server, thus must not send dhcp reply messages. In case of it, the controller will install a flow which drops all the dhcp server packets from a vm port, matching fields includeing protocol:udp, scr port:67 and dst port:68. "},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"2.4\tForwading Security Table"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a7e1126_a9444649","line":29,"in_reply_to":"3a7e1126_ded838f2","updated":"2015-12-23 01:41:02.000000000","message":"Yes, I agree with you and I also think it is more suitable put into port security scope, not security groups. So, I will remove this part in the next patch.","commit_id":"05d8a00f1c15a94f3f55d1290f24fcc7038627af"},{"author":{"_account_id":18668,"name":"ding bo","email":"longddropt@163.com","username":"longddropt"},"change_message_id":"1c6ecc460de767388e068a556bd2bcb317dee7c5","unresolved":false,"context_lines":[{"line_number":26,"context_line":"Ingress security group table provides following features as below, and the flows installed in this table are all proactive way."},{"line_number":27,"context_line":"1)Anti-arp ip spoofing"},{"line_number":28,"context_line":"  When controller has detected the Security Group is assigned to a local port, it install this flow. This flow matches the in_port and the port\u0027s mac and ip pair and passes it to the next table. If doesnot match, it drops the packet."},{"line_number":29,"context_line":"2)Anti-dhcp spoofing"},{"line_number":30,"context_line":"  A vm is never being expected to be a dhcp server, thus must not send dhcp reply messages. In case of it, the controller will install a flow which drops all the dhcp server packets from a vm port, matching fields includeing protocol:udp, scr port:67 and dst port:68. "},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"2.4\tForwading Security Table"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a7e1126_0c68ecf4","line":29,"in_reply_to":"5a710552_0bdc35e3","updated":"2015-12-17 06:07:56.000000000","message":"I think the end-user should never has the power to assign ip addr to other users\u0027s vm. In fact, this is the admin right which normal tenant should not have","commit_id":"05d8a00f1c15a94f3f55d1290f24fcc7038627af"},{"author":{"_account_id":7805,"name":"Li Ma","email":"skywalker.nick@gmail.com","username":"Nick"},"change_message_id":"935a61ae2986b23bc2bb011ba8d4a2a8b45486e2","unresolved":false,"context_lines":[{"line_number":33,"context_line":"This section describe all the handling in the pipeline for traffic forwarding. When traffic leaves Packet Classifier Table and before it goes into L3 forwarding table, it enters into forwarding security group table. "},{"line_number":34,"context_line":"The procedures are detailed below, and the flows mentioned in this section are reactive way."},{"line_number":35,"context_line":"\tThe forwarding security table is empty at beginning; it means all packets coming into this table will pack into the controller. "},{"line_number":36,"context_line":"\tDragonflow controller inspects the security rules corresponding to the packet\u0027s key words. For example, the dst ip, the protocol, the tcp upd port number. If controller decides to forward such packet, it will install a flow into the integrity bridge to let this packet go to the next table for further processing. At reverse, it will install a drop flow matching this packet. As a result, such packet will be discarded. "},{"line_number":37,"context_line":"\tBecause ovs already supports connect tracking, the controller will install a flow matching the corresponding state to let such packet pass."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"2.5\tEgress Security Table"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a710552_8ba105ac","line":36,"updated":"2015-12-15 10:37:54.000000000","message":"upd -\u003e udp","commit_id":"05d8a00f1c15a94f3f55d1290f24fcc7038627af"},{"author":{"_account_id":18668,"name":"ding bo","email":"longddropt@163.com","username":"longddropt"},"change_message_id":"1c6ecc460de767388e068a556bd2bcb317dee7c5","unresolved":false,"context_lines":[{"line_number":33,"context_line":"This section describe all the handling in the pipeline for traffic forwarding. When traffic leaves Packet Classifier Table and before it goes into L3 forwarding table, it enters into forwarding security group table. "},{"line_number":34,"context_line":"The procedures are detailed below, and the flows mentioned in this section are reactive way."},{"line_number":35,"context_line":"\tThe forwarding security table is empty at beginning; it means all packets coming into this table will pack into the controller. "},{"line_number":36,"context_line":"\tDragonflow controller inspects the security rules corresponding to the packet\u0027s key words. For example, the dst ip, the protocol, the tcp upd port number. If controller decides to forward such packet, it will install a flow into the integrity bridge to let this packet go to the next table for further processing. At reverse, it will install a drop flow matching this packet. As a result, such packet will be discarded. "},{"line_number":37,"context_line":"\tBecause ovs already supports connect tracking, the controller will install a flow matching the corresponding state to let such packet pass."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"2.5\tEgress Security Table"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a7e1126_0c4f8c93","line":36,"in_reply_to":"5a710552_8ba105ac","updated":"2015-12-17 06:07:56.000000000","message":"Thanks for your reminding:)","commit_id":"05d8a00f1c15a94f3f55d1290f24fcc7038627af"},{"author":{"_account_id":7805,"name":"Li Ma","email":"skywalker.nick@gmail.com","username":"Nick"},"change_message_id":"935a61ae2986b23bc2bb011ba8d4a2a8b45486e2","unresolved":false,"context_lines":[{"line_number":39,"context_line":"2.5\tEgress Security Table"},{"line_number":40,"context_line":"This section describes all the handling in the pipeline for Egress traffic. "},{"line_number":41,"context_line":"Egress defaults to pass all traffic since there are no requirements for egresss security table."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"3\tReferences"},{"line_number":44,"context_line":"https://github.com/justinpettit/ovs/tree/conntrack"},{"line_number":45,"context_line":"https://lwn.net/Articles/652967/"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a710552_661170ac","line":42,"updated":"2015-12-15 10:37:54.000000000","message":"Neutron iptables implementation has another problem that I\u0027d like to share. We always set ACL at receiver\u0027s side and then all the invalid traffic is allowed to flow in the fabric just like the normal east/west traffic and finally, the packets are dropped at the receiver side. It greatly affect the fabric as all the packets are invalid and which should be dropped as early as possible. However it isn\u0027t that easy to be achieved by linux-net-tools.\n\nWhen using OpenFlow, due to its nature of reactive behavior, I think it is possible to calculate at the local controller and install the corresponding dropping flows at the sender side, because the sender\u0027s local controller is able to get the dst ip/protocol/port and also know whether it is valid or not, which can greatly prevent from east/west bandwidth outage when invalid attack happens and also greatly enhance the security and stability.\n\nAll-in-all, everything happens at the sender\u0027s side, no matter how user defines the ACL.\n\nWhat do you think of that?","commit_id":"05d8a00f1c15a94f3f55d1290f24fcc7038627af"},{"author":{"_account_id":7805,"name":"Li Ma","email":"skywalker.nick@gmail.com","username":"Nick"},"change_message_id":"327f52c9b127d7369e5512033317fb7a5ec91278","unresolved":false,"context_lines":[{"line_number":39,"context_line":"2.5\tEgress Security Table"},{"line_number":40,"context_line":"This section describes all the handling in the pipeline for Egress traffic. "},{"line_number":41,"context_line":"Egress defaults to pass all traffic since there are no requirements for egresss security table."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"3\tReferences"},{"line_number":44,"context_line":"https://github.com/justinpettit/ovs/tree/conntrack"},{"line_number":45,"context_line":"https://lwn.net/Articles/652967/"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a7b0d38_d7ca34a1","line":42,"in_reply_to":"1a7b0d38_d28270c8","updated":"2015-12-24 01:59:24.000000000","message":"The drawbacks of it is that the delay of 1st packet, maybe 100x delay compared with normal stream. Once I evaluated Midonet, it shows 50-80ms at 1st ping, then lower down to 0.5ms at 2nd ping. Actually, I\u0027m always OK with this performance result, thinking of it prevents 75+% invalid east/west traffic. But I\u0027m not sure others\u0027 thoughts.","commit_id":"05d8a00f1c15a94f3f55d1290f24fcc7038627af"},{"author":{"_account_id":18668,"name":"ding bo","email":"longddropt@163.com","username":"longddropt"},"change_message_id":"83bf6713c5343f6391ef2df0a6ecea0d9ca136cb","unresolved":false,"context_lines":[{"line_number":39,"context_line":"2.5\tEgress Security Table"},{"line_number":40,"context_line":"This section describes all the handling in the pipeline for Egress traffic. "},{"line_number":41,"context_line":"Egress defaults to pass all traffic since there are no requirements for egresss security table."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"3\tReferences"},{"line_number":44,"context_line":"https://github.com/justinpettit/ovs/tree/conntrack"},{"line_number":45,"context_line":"https://lwn.net/Articles/652967/"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a7b0d38_eafdeb3a","line":42,"in_reply_to":"1a7b0d38_d7ca34a1","updated":"2015-12-25 02:42:10.000000000","message":"I think it is the SDN\u0027s way to solve problems. Preinstall all flows is inconvenient due to the lack of egree_port key words in ovs match fields. So it is difficult to match a port\u0027s ingress rules directly into ovs flows. And just because we install flow as needed, we gain a quick set-up speed and avoid to install some redundant flows which probably never be used.","commit_id":"05d8a00f1c15a94f3f55d1290f24fcc7038627af"},{"author":{"_account_id":7805,"name":"Li Ma","email":"skywalker.nick@gmail.com","username":"Nick"},"change_message_id":"7e931db8b587f76a9f02f02f4d80bcd69874cb51","unresolved":false,"context_lines":[{"line_number":39,"context_line":"2.5\tEgress Security Table"},{"line_number":40,"context_line":"This section describes all the handling in the pipeline for Egress traffic. "},{"line_number":41,"context_line":"Egress defaults to pass all traffic since there are no requirements for egresss security table."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"3\tReferences"},{"line_number":44,"context_line":"https://github.com/justinpettit/ovs/tree/conntrack"},{"line_number":45,"context_line":"https://lwn.net/Articles/652967/"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a7e1126_f0f8bc7e","line":42,"in_reply_to":"3a7e1126_42fc7b3e","updated":"2015-12-17 08:00:16.000000000","message":"Personally, I prefer the 2nd method, doing calculation and installation at the first packet.\n\n1st method to hold everything in memory at the local side seems not realistic because all the controller will be notified when some rules are updated and actually not related to most of the controllers.","commit_id":"05d8a00f1c15a94f3f55d1290f24fcc7038627af"},{"author":{"_account_id":18668,"name":"ding bo","email":"longddropt@163.com","username":"longddropt"},"change_message_id":"2255df2ddde19f7a34a14b1ded690ac17bd589ab","unresolved":false,"context_lines":[{"line_number":39,"context_line":"2.5\tEgress Security Table"},{"line_number":40,"context_line":"This section describes all the handling in the pipeline for Egress traffic. "},{"line_number":41,"context_line":"Egress defaults to pass all traffic since there are no requirements for egresss security table."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"3\tReferences"},{"line_number":44,"context_line":"https://github.com/justinpettit/ovs/tree/conntrack"},{"line_number":45,"context_line":"https://lwn.net/Articles/652967/"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a7b0d38_d28270c8","line":42,"in_reply_to":"3a7e1126_f0f8bc7e","updated":"2015-12-23 01:41:02.000000000","message":"Yes, but the problem is the efficiency of local controller searching the ingress rules of a security group associating with a remote port in the distributed database.","commit_id":"05d8a00f1c15a94f3f55d1290f24fcc7038627af"},{"author":{"_account_id":11343,"name":"Gal Sagie","email":"gal.sagie@gmail.com","username":"GalSagie"},"change_message_id":"27040d11b1c5cf73e5414fe2227fc5e5c911a754","unresolved":false,"context_lines":[{"line_number":39,"context_line":"2.5\tEgress Security Table"},{"line_number":40,"context_line":"This section describes all the handling in the pipeline for Egress traffic. "},{"line_number":41,"context_line":"Egress defaults to pass all traffic since there are no requirements for egresss security table."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"3\tReferences"},{"line_number":44,"context_line":"https://github.com/justinpettit/ovs/tree/conntrack"},{"line_number":45,"context_line":"https://lwn.net/Articles/652967/"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5a710552_325cef4a","line":42,"in_reply_to":"5a710552_661170ac","updated":"2015-12-15 15:57:26.000000000","message":"Li Ma, thats actually very similar to what i had in mind when drawing the pipeline and thinking about this.\n\nI think it makes a lot of sense.","commit_id":"05d8a00f1c15a94f3f55d1290f24fcc7038627af"},{"author":{"_account_id":18668,"name":"ding bo","email":"longddropt@163.com","username":"longddropt"},"change_message_id":"1c6ecc460de767388e068a556bd2bcb317dee7c5","unresolved":false,"context_lines":[{"line_number":39,"context_line":"2.5\tEgress Security Table"},{"line_number":40,"context_line":"This section describes all the handling in the pipeline for Egress traffic. "},{"line_number":41,"context_line":"Egress defaults to pass all traffic since there are no requirements for egresss security table."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"3\tReferences"},{"line_number":44,"context_line":"https://github.com/justinpettit/ovs/tree/conntrack"},{"line_number":45,"context_line":"https://lwn.net/Articles/652967/"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3a7e1126_42fc7b3e","line":42,"in_reply_to":"5a710552_661170ac","updated":"2015-12-17 06:07:56.000000000","message":"Yes, I think the reason why neutron set ACL at receiver side is that the security group\u0027s ingress rules \u0026 egress rules is all binded to a neutron port. As a result, all the corresponding ip table rules is set at that port side, despite of sender or receiver. It is easy to implement. For example, when update a port\u0027s security rule, neutron only needs to notify the agent on the host where the port is binding, and update the ingress ip table rules of that port. This is because neutron is lack of reacitve flow installation mode. Naturally, Dragonflow has the ability to dynamically install flow. However, the real challenge of drop packets at sender side is the data sync of local compute node and controller node(distributed DB). Two option: 1. every compute node knows all security rules of all ports. 2. when local controller receive a packet in message, it will retrieve the rules from upstream DB according the the DST neutron port. Both has pro and cons themselves. I will do some further research on it.","commit_id":"05d8a00f1c15a94f3f55d1290f24fcc7038627af"},{"author":{"_account_id":7805,"name":"Li Ma","email":"skywalker.nick@gmail.com","username":"Nick"},"change_message_id":"7282bd408131bf833d89a71a62905476a811e0e6","unresolved":false,"context_lines":[{"line_number":18,"context_line":"between VM and ovs bridge. However, it introduces unnecessary overhead and"},{"line_number":19,"context_line":"latency for traffic forwarding."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"As connection tracking is supported in ovs v2.4.0 now, seurity group iptables"},{"line_number":22,"context_line":"rules can be translated into openflow tables and installed in ovs bridge to"},{"line_number":23,"context_line":"implement traffic security control."},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a7b0d38_6c913299","line":21,"range":{"start_line":21,"start_character":55,"end_line":21,"end_character":62},"updated":"2015-12-24 06:01:52.000000000","message":"security","commit_id":"42cd9afae7f7a30aa13cf4fc9f12a1a896ddd536"},{"author":{"_account_id":18668,"name":"ding bo","email":"longddropt@163.com","username":"longddropt"},"change_message_id":"8a08c6e9146b82a45532069cc72397f5abefc22a","unresolved":false,"context_lines":[{"line_number":18,"context_line":"between VM and ovs bridge. However, it introduces unnecessary overhead and"},{"line_number":19,"context_line":"latency for traffic forwarding."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"As connection tracking is supported in ovs v2.4.0 now, seurity group iptables"},{"line_number":22,"context_line":"rules can be translated into openflow tables and installed in ovs bridge to"},{"line_number":23,"context_line":"implement traffic security control."},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a7b0d38_ca990f21","line":21,"range":{"start_line":21,"start_character":55,"end_line":21,"end_character":62},"in_reply_to":"1a7b0d38_6c913299","updated":"2015-12-25 02:43:51.000000000","message":"Thanks :)","commit_id":"42cd9afae7f7a30aa13cf4fc9f12a1a896ddd536"},{"author":{"_account_id":13070,"name":"Eran Gampel","email":"eran@gampel.net","username":"Gampel"},"change_message_id":"36c01fa5b87e14e37bdb7ba3eabe182459f77982","unresolved":false,"context_lines":[{"line_number":56,"context_line":"1) add a new table which implements security group between service traffic table"},{"line_number":57,"context_line":"   and L2 lookup table."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"2) add default packin controller flow which means all flows defaults to"},{"line_number":60,"context_line":"   controller"},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"3) install \"pass\" or \"drop\" flow reactively according to the security rules."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a7b0d38_be714546","line":59,"range":{"start_line":59,"start_character":22,"end_line":59,"end_character":32},"updated":"2015-12-26 21:31:49.000000000","message":"If I understand correctly you are suggesting full reactive implementation for SG.(you would have to simulate security rules engine in dragonflow similar to what ovs-vswitchd all ready provides if we translate the SG rules into ovs ACLs   ) \nIn my opinion we should adopt a hybrid(reactive , proactive) approach or full proactive.\nThe big challenge is how to implement the ipset functionality howto map the different Zone and different SG and buid the flow that redirect to CT with the correct zone mapped and returned the traffic to the matching \"SG flows\"  \n\nOther key guidelines/challenges in my opinion are\n1) Set only relevant SG for the local ports \n2) Translate a group in flow only once even if you have multiple ports on the same group\n3) use in port to redirect to the corresponding group or  mark a reg with the group ID by the in port and with the CT zone \n4) which flows require state and need to be redirected to the connection tracking module and which are stateless, SG  implicitly allow all traffic stared form the VM (related and established) \n5) How do we create the connection tracking Zone mapping ?\n5) There are two possible matching by remote  SG and by cidr we need to support both of them","commit_id":"42cd9afae7f7a30aa13cf4fc9f12a1a896ddd536"},{"author":{"_account_id":18668,"name":"ding bo","email":"longddropt@163.com","username":"longddropt"},"change_message_id":"3a07c2a767b394572701df434e6f37965b662d85","unresolved":false,"context_lines":[{"line_number":56,"context_line":"1) add a new table which implements security group between service traffic table"},{"line_number":57,"context_line":"   and L2 lookup table."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"2) add default packin controller flow which means all flows defaults to"},{"line_number":60,"context_line":"   controller"},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"3) install \"pass\" or \"drop\" flow reactively according to the security rules."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a7b0d38_9a656cb6","line":59,"range":{"start_line":59,"start_character":22,"end_line":59,"end_character":32},"in_reply_to":"1a7b0d38_be714546","updated":"2015-12-28 01:41:41.000000000","message":"I think we can map SG rules into different zones according to the network which the port binded in SG rules belongs to. The problem is not the egress SG rule of local port, we can easily map SG rules into flow(either statefule or nonstateful) by in_port, but it is difficult to map the ingress rules of local port due to the lack of \"egress port\" in the match field of ovs, maybe we can rely on other match field such as src ip ,protocol type etc.","commit_id":"42cd9afae7f7a30aa13cf4fc9f12a1a896ddd536"},{"author":{"_account_id":7805,"name":"Li Ma","email":"skywalker.nick@gmail.com","username":"Nick"},"change_message_id":"7282bd408131bf833d89a71a62905476a811e0e6","unresolved":false,"context_lines":[{"line_number":65,"context_line":"   default flow, so the same packet will pack-in controller only once. This"},{"line_number":66,"context_line":"   flow uses src ip and dst ip to match the corresponding egress rules of local"},{"line_number":67,"context_line":"   port and ingress rules of remote port. Notice that dropping packet always"},{"line_number":68,"context_line":"   happens in the sender side to avoid unnecessary wasting of band."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"4) local controller only caches the security group rules of local port. When local"},{"line_number":71,"context_line":"   permits the packet to pass, local controller also look up the rules of remote"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a7b0d38_8cba5e09","line":68,"range":{"start_line":68,"start_character":62,"end_line":68,"end_character":66},"updated":"2015-12-24 06:01:52.000000000","message":"bandwidth","commit_id":"42cd9afae7f7a30aa13cf4fc9f12a1a896ddd536"},{"author":{"_account_id":18668,"name":"ding bo","email":"longddropt@163.com","username":"longddropt"},"change_message_id":"8a08c6e9146b82a45532069cc72397f5abefc22a","unresolved":false,"context_lines":[{"line_number":65,"context_line":"   default flow, so the same packet will pack-in controller only once. This"},{"line_number":66,"context_line":"   flow uses src ip and dst ip to match the corresponding egress rules of local"},{"line_number":67,"context_line":"   port and ingress rules of remote port. Notice that dropping packet always"},{"line_number":68,"context_line":"   happens in the sender side to avoid unnecessary wasting of band."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"4) local controller only caches the security group rules of local port. When local"},{"line_number":71,"context_line":"   permits the packet to pass, local controller also look up the rules of remote"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a7b0d38_6aa01b44","line":68,"range":{"start_line":68,"start_character":62,"end_line":68,"end_character":66},"in_reply_to":"1a7b0d38_8cba5e09","updated":"2015-12-25 02:43:51.000000000","message":"I will correct soon :)","commit_id":"42cd9afae7f7a30aa13cf4fc9f12a1a896ddd536"},{"author":{"_account_id":13070,"name":"Eran Gampel","email":"eran@gampel.net","username":"Gampel"},"change_message_id":"36c01fa5b87e14e37bdb7ba3eabe182459f77982","unresolved":false,"context_lines":[{"line_number":72,"context_line":"   port according to the dst ip from the distributed db(the local controller"},{"line_number":73,"context_line":"   does only cache local and related remote port\u0027s security gruop rules)"},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"5) When security group rule associates with a port has been updated. The local"},{"line_number":76,"context_line":"   controller must delete the corresponding \"pass\" and \"drop\" flows in the security"},{"line_number":77,"context_line":"   group table matching the keys of src ip or dist ip. This means the local controller"},{"line_number":78,"context_line":"   not only needs to care security group rules of local port but also remote port."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a7b0d38_5e914146","line":75,"range":{"start_line":75,"start_character":3,"end_line":75,"end_character":7},"updated":"2015-12-26 21:31:49.000000000","message":"I think it will be better to include an image that describe the proposed pipe line it will be easier to understand","commit_id":"42cd9afae7f7a30aa13cf4fc9f12a1a896ddd536"},{"author":{"_account_id":18668,"name":"ding bo","email":"longddropt@163.com","username":"longddropt"},"change_message_id":"3a07c2a767b394572701df434e6f37965b662d85","unresolved":false,"context_lines":[{"line_number":72,"context_line":"   port according to the dst ip from the distributed db(the local controller"},{"line_number":73,"context_line":"   does only cache local and related remote port\u0027s security gruop rules)"},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"5) When security group rule associates with a port has been updated. The local"},{"line_number":76,"context_line":"   controller must delete the corresponding \"pass\" and \"drop\" flows in the security"},{"line_number":77,"context_line":"   group table matching the keys of src ip or dist ip. This means the local controller"},{"line_number":78,"context_line":"   not only needs to care security group rules of local port but also remote port."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1a7b0d38_fa74b068","line":75,"range":{"start_line":75,"start_character":3,"end_line":75,"end_character":7},"in_reply_to":"1a7b0d38_5e914146","updated":"2015-12-28 01:41:41.000000000","message":"I will draw a picture later to describe it:)","commit_id":"42cd9afae7f7a30aa13cf4fc9f12a1a896ddd536"}]}