[IPsec] Some thoughts regarging draft-hopps-ipsecme-iptfs-01

["Valery Smyslov" <[e-mail]>]

Hi,

after reading through draft-hopps-ipsecme-iptfs-01 I have some thoughts.

1. I think it's a wrong decision to support tunnel mode ESP only. IP-TFS for transport mode ESP
    is equally important because one of the widely used scenario is to combine general purpose
    tunneling (like GRE) with transport mode ESP. In this case traffic flowing over such SA
    will in fact be tunnel traffic from several hosts, but the SA is created in transport mode.
    For this reason I think that IP-TFS must support transport mode SA either.

2. I don't think new IP protocol number is needed at all. Since SA is created with IKEv2,
     it is always known whether it is IPTFS SA or ordinary SA, so "Next Protocol"
     field in ESP trailer is redundant and can be filled in with arbitrary value (say zero). 
    If a new protocol number is allocated, it will never appear in any network header 
    except for encrypted ESP trailer, still it will occupy a codepoint and some middle-box 
    vendors will probably  try to figure out what to do with it (nothing), adding some confusion. 
    Moreover, I suspect that an idea to allocate a codepoint from rather limited resource
    (only 255 are available and more than half of them is already allocated), that will never
    appear in any network header and in reality is not needed, will meet a negative reaction from 
   INT area guys. So, I think we should not go this way and just use zero (or other value)
    as a filler for "Next Header" field.

3. I think that using new Transform Type for IP-TFS negotiation is a bad idea.
   Transforms are best thing when combination of them matters. I don't think
    that it is the case - negotiation of using IP-TFS is orthogonal to negotiation
    of algorithms to use. I cannot imagine that one wants to use IPTFS with 
    say AES-GCM and doesn't want to do it with say Chacha+Poly. 
    So I believe it is better to negotiate IPTFS by means of notifications, as it is done 
    with transport mode or WESP. So, a new notification (let call it USE_IPTFS) should be 
    introduced, which will contain data regarding whether congestion control
    is needed and whether fragmentation is allowed. If the responder supports
    IPTFS it will return back this notification with the data reflecting its choice
    of IPTFS features. In this case IPTFS_REQUIREMENTS notification is not needed.

4. I'd like to see more text in the draft regarding reassembling of incoming packets.
    It seems to me that it can be done pretty easy by linking the reassembly logic
    with replay protection window. Note, that this won't work in case of
    multicast SA with several senders.

5. In general it seems to me that multicast case must be discussed in more details, 
     since in this case neither congestion control nor fragmentation are possible.

6. I think that having inner IP packets properly aligned is a good idea.

7. I don't think that late-enabling of IP-TFS described in section 2.4
    is really needed. It adds unnecessary complexity and somewhat contradicts 
    to what is stated in section 2.3.

Regards,
Valery.