Dear Sowmini: > El 19 jun 2016, a las 23:45, Sowmini Varadhan <[email protected]> > escribió: > > On (06/19/16 20:06), Rafa Marin Lopez wrote: >>> I had a related question Section 8.2, #2 as well: is the first >>> data packet in the clear or not? If it is not in the clear, how >>> can you determine the flow in the general case? >> >> [Rafa] Please be aware that, if ESP (AH does not encrypt the packet) >> has been applied to the packet before reaching the GW1 the IP header of >> that packet is still visible (it is not encrypted). And based on that >> information there would be SPD entries so that the IPsec implementation >> would act based on that visible information. Thus, adding the controller >> does not change that behavior. So I am not sure the issue/problem you >> may have in mind. > > if the first packet is using AH, then the sender has alredy made > some assumption about the auth key. How is the receiver going to > know that key (assuming that AH has been added for a reason)?
[Rafa] The quick answer would be the controller have to install what is required in both end points. However, from your questions, we have to clarify first what is the use case we are discussing, which is the following: host1-—gw1——IPsec——gw2—-host2. That is, a typical GW-to-GW scenario for IPsec tunnel. Imagine that host1 sends a IP packet to host2. The gw1 will get the IP packet and it has to determine what to do. The gw1 contacts the controller and the controller installs what it is required in both gw1 and gw2 (e.g. IPsec tunnel in ESP mode, and the key material). With that information the gw1 can tunnel the IP packet coming from host1 to host2 inside a IPsec tunnel whose endpoints are gw1 and gw2. Thus, IPsec SA is between gw1 and gw2 and the controller configures both. That would be the reactive case because everything is triggered in the first packet arriving the gw1. I agree that gw1 must have something like a default behavior saying “go to the controller when you do not know what to do” (which is similar to packetin in openflow). Another approach is to just sending the SPD/SAD entries to gw1 and gw2 (the controller knows that from the policies obtained from the northbound api) even when either gw1 or gw2 have not observed any traffic with those features. That is what I called proactive. > And what is the point of the following (quoted from Section 8.2) > if the sender is already making some assumptions about the AH > parameters for the first packet? > > "2. The SDN Controller looks for security policies in its SPD table > and decides that the flow MUST be protected, for example, with > IPsec ESP in tunnel mode. > > 3. The SDN controller derives keys for the IPsec tunnel and enforces > them, along with other information required, such as IPsec mode > (ESP or AH), into both gateways' IPsec Security Association > Database (SAD).” [Rafa] As you can see, this text applies to the example I just mentioned. Do you want to consider IPsec between host1 to host2 in an end-to-end fashion (transport mode)? If the answer is yes, that should be fairly similar. We can add also that use case to the next version of the I-D. > > To put this in another way, isnt this a chicken-and-egg problem: [Rafa] I do not think so. > receiver is supposed to use the first data packet figure out the > sadb/spd configuration (which may or may not include both AH and ESP), > but the first packet itself has some AH (with no ESP) based on <what > negotiation?>? [Rafa] I mentioned AH just to show that packets may be still in clear. In any case, to your question and considering our example, if the first packet coming from host1 to host2 through gw1 has AH, it does not matter for gw1. It would mean that there is some an IPsec SA AH in transport mode between host1 and host2. The behavior in the gw1 will be same as described above because they are different IPsec SA between different end-points (host1-host2 and gw1-gw2). Now, you may ask: how does host1 know that the IP packet to host2 must be protected with AH. If we follow the approach of using a controller, the controller should have installed IPsec policies in both host1 and host2. > >>> If it is in >>> the clear, what is the scope of the security consideration? >> >> [Rafa] Not sure about what do you mean? Are you referring to section >> 9 or other aspect? > > Is the IPsec SA/SPD negotiated in Section 8.1 applicable/different > for the first packet compared to the rest of the flow? No, it isn’t. This first packet that triggers everything (in the reactive case) will be protected in the same way that the rest of the flow. Although perhaps you question is related to what I have just mentioned about the behavior regarding the first packet: "go to the controller when you do not know what to do”. This is a new behavior... I agree (it is something like OpenFlow does) that we should definitely describe for the reactive case. In the proactive case, no need for that. Best Regards. > > --Sowmini ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: [email protected] ------------------------------------------------------- _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
