On Tue, Nov 28, 2017 at 9:28 AM, Dmitry Eremin-Solenikov < dmitry.ereminsoleni...@linaro.org> wrote:
> Hello, > > On 20/11/17 18:23, Bill Fischofer wrote: > > Traffic Flow Confidentiality (TFC) is a feature of SAs according to RFC > > 4303 that must be negotiated on a per-SA basis before it is used. So > > This would need to be hooked into higher-level protocols. > > > > From an ODP perspective, it would be an additional set of parameters on > > the odp_ipsec_sa_create() API. Not clear this is something we should > > worry about for Tiger Moth, but something to consider as an addition in > > the future. > > In fact I think that control can go to application level. I was thinking > about allowing application to specify if outgoing packet is dummy or > not. In fact I'm going to propose the possibility to specify if outgoing > packet is IPv4, IPv6 or dummy. > Whether the outbound packets are IPv4 or IPv6 is controlled by the tunnel mode configuration. For transport mode the input packet already has the L3/L4 headers it needs. TFC enablement should be another odp_ipsec_sa_param_t option. Dummy packets for output can be another odp_ipsec_out_opt_t bit setting. For RX, I think we'd want to report dummy packet receipt as another odp_ipsec_warn_t bit. I'm very reluctant to have ODP discard anything as that means that the application can never see it and we'd have to maintain stats for these discards anyway. Applications using IPsec should understand these packets since they have to negotiate them anyway and should take whatever action they wish with them. ODP should not limit application freedom of action in this regard by making these decisions itself. > > > > > On Mon, Nov 20, 2017 at 8:37 AM, Dmitry Eremin-Solenikov > > <dmitry.ereminsoleni...@linaro.org > > <mailto:dmitry.ereminsoleni...@linaro.org>> wrote: > > > > Hello, > > > > I was thinking about another minor part of IPsec RFCs: dummy packets > > used to mask traffic statistics. IPsec implementation is required to > > drop ESP packets with NH = 59 (no next header) on receiver side and > is > > expected to be able to generate these packets on transmitter side. > > Currently we do not provide a way to inject these packets in any way. > > > > Possible solutions: > > > > TX side: > > - Add API call to transmit single packet. > > > > - Extend transmit parameters to specify next header (IPv4, IPv6 or > > NoNH) for each packet to be transmitted (per-packet or per-odp call). > > > > - ??? > > > > RX side: > > - Silently drop NoNH packets > > > > - Report NoNH packets to app via error or status event mechanism. > > > > - ??? > > > > -- > > With best wishes > > Dmitry > > > > > > > -- > With best wishes > Dmitry >
