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.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
