Hi Christian,
I agree with what Lou with regards to it going too far to recast/redirect this
work any further. I did do a round
of changes based on our agreement to help with future uses, and while it's nice
that this work could lead to
these uses, those should be documented in another document at this point. The
focus of this work has and
should continue to be traffic flow security.
Here we disagree. My point is that you define a very good mechanism
that can be used not only for IP-TFS, but for other purposes too.
I fully understand that IP-TFS was your primary focus and I agree
the document to remain focused on it. However, if the document
is kept in its current form any attempt to use it for other applications
will look as an improper use of mechanism, because the way document
is organized highly ties the mechanism and its application.
A compromise and to address your concern that other uses might look improper
I've changed the abstract to include this final
sentence:
"The mechanisms defined in this document are generic with the intent of
allowing for non-TFS uses, but such uses are outside the
scope of this document."
The introduction to include this final paragraph:
"The mechanisms defined in this document are generic with the intent of
allowing for non-TFS uses, but such uses are outside the
scope of this document."
And the "Packets and Data Formats" top level section to start:
"The packet and data formats defined below are generic with the intent of
allowing for non-IP-TFS uses, but such uses are outside
the scope of this document."
I believe this addresses your concern about other uses looking improper.
That changes are the very minimal ones and in my opinion they're not
enough.
The document still looks like a mess, because it constantly used term
"IP-TFS"
when describing a generic behavior of Aggregation and Fragmentation
mode.
Few examples:
2. The IP-TFS Tunnel
As mentioned in Section 1 IP-TFS utilizes an IPsec [RFC4303] tunnel
(SA) as it's transport. To provide for full TFC, fixed-sized
encapsulating packets are sent at a constant rate on the tunnel.
The egress of the IP-TFS tunnel MUST allow for and expect the ingress
(sending) side of the IP-TFS tunnel to vary the size and rate of sent
encapsulating packets, unless constrained by other policy.
IP-TFS aggregates as well as fragments the inner IP traffic flow into
fixed-sized encapsulating IPsec tunnel packets.
In particular IP-TFS never maps the inner DF bit as it is
unrelated to the IP-TFS tunnel functionality; IP-TFS never IP
fragments the inner packets and the inner packets will not affect the
fragmentation of the outer encapsulation packets. Likewise, the ECN
value need not be mapped as any congestion related to the constant-
send-rate IP-TFS tunnel is unrelated (by design!) to the inner
traffic flow
An example IP-TFS packet flow can be found in Appendix A.
And so on. I think the text must be cleaned up to be more accurate
with this regard.
I've incorporated your other suggestions from below.
Please see my comments (I removed parts where we are in concert).
9. Section 2.2.3:
When using the AGGFRAG_PAYLOAD in conjunction with replay detection,
the window size for both MAY be reduced to share the smaller of the
two window sizes. This is b/c packets outside of the smaller window
but inside the larger would still be dropped by the mechanism with
the smaller window size.
I wonder why MAY is used here. It should be MUST instead.
As you explained there is no point for the sizes to be different.
They remain different mechanisms and the user may wish to have them treated
differently (e.g., logging
replayed packets).
My question was regarding "MAY" vs "MUST". Even if these are different
mechanisms, what is the reason for having different window sizes if both
mechanisms
are employed? I may yet understand that reassembly window may be shorter
then replay window (you will just have a penalty of dropping too old packets
even when replay protection allows them in), but what may be the reason
for having reassembly window longer than replay window? If you have some gaps
at the far left end of reassembly window waiting for missing packets,
you'll never receive them if replay window is shorter - they will fall
outside it. So, it's just a waste of resources.
The implementation may wish to allow the user to have replayed packets logged
(one can have a very large replay window w/o consuming
many resources).
Well, I probably was unclear, but you missed my point. I'll try again.
The current text says that if both replay protection and AGGFRAG
are employed, then replay protection window and reassembling window
MAY
be of the same size, which is the smaller of both.
Since MAY means that you think it's OK for these windows to be of
different
sizes in this case, I wondered in which situations you think it's OK.
You gave me an example, for situation when replay window is longer
than
reassembly window, which I can reluctantly buy (I still think that
it's a waste
of resources: some delayed packets will pass the replay protection,
decrypted and then dropped because they would fall outside reassembly
window).
But can you please give me an example when it's useful to have
reassembly
window longer than replay protection window?
Consider an example when reassembly window size is 100 and replay
protection window size is 10.
For simplicity let's assume that reassembly window at the moment is
filled with packets with odd SNs
starting from 1 to 99. So, you are waiting for the rest packets with
even SNs from 0 to 98 to be able
to complete reassembly process. But since replay protection window
size is only 10 and the
most recently received ESP packet has SN 99, you never receive
packets with SNs from 0 to 89,
(because the will be dropped by replay protection logic) and the
first 90 packets will never be reassembled.
It's just a waste of resources.
So, I think that MAY above should be at least SHOULD. Or leave it as
MAY and say that
reassembly window SHOULD NOT (MUST NOT?) be longer that replay
protection (for the reason
outlined above).
10. Section 2.2.3:
Finally, as sequence numbers are reset when switching SAs (e.g., when
re-keying a child SA), an implementation SHOULD NOT send initial
fragments of an inner packet using one SA and subsequent fragments in
a different SA.
Two issues here - first why SHOULD NOT and not MUST NOT?
In general you cannot reliably reassemble packet if it is fragmented over
several SAs, so it will be dropped. Why do you allow this?
Changed to MUST NOT.
Then, IPsec architecture allows several parallel ESP SAs
to co-exist with the intention that kernel may use any of these SAs to send
packets
(e.g. for improving performance, see draft-pwouters-multi-sa-performance).
I think you should mention that in this case a care must be taken not to
fragment outgoing packets over several parallel SAs. I.e. if a packet get
fragmented,
all its fragments must be sent over single ESP SA.
Covered by the switch to MUST NOT.
Well, this text is explicitly about "sequence numbers are reset when switching
SAs".
I think it's better to generalize it and say that "packet fragmentation MUST
not take
place over different SAs". This will cover both cases - rekeying and parallel
SAs.
It's explaining the restriction. This adds information/justification w/o
changing the actual requirement. I think that's a good
thing not bad.
If you have several parallel SAs their SNs are not reset, they are
just different...
OK, I can live with this, although I still think the text is a bit
confusing.
20. Section 6.1.4:
0:
6 bits - reserved, MUST be zero on send, unless defined by later
specifications.
Add a sentence that these bits MUST be ignored on receipt.
They must not be ignored. If they are set and they and not understood then
AGGFRAG mode will not be
enabled as indicated in section 5.1
Section 5.1 is about USE_AGGFRAG notification, here we talk about
Reserved bits AGGFRAG_PAYLOAD. How they are related?
As implementer I have a question - what should I do if these bits
are non-zero on receipt? The draft is silent about this.
I think maybe you mixed something up in your reading? Section 6.1.4 is:
" <https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-06#section-6.1.4>
6.1.4. IKEv2 USE_AGGFRAG Notification Message"
It is not about the AGGFRAG_PAYLOAD.
You are right, I somehow mixed up these sections. That's probably
because
the description of USE_AGGFRAG is split over 5.1 and 6.1.4, that
was a cause of my confusion. I'd rather merge them not to confuse
other readers :-)
22. Security Considerations.
Add a text that correct functionality of the AGGFRAG mode
requires restoring packets order on the receiver. Since this
is done by utilizing ESP Sequence Number field, the ESP
header must be authenticated, and thus the ESP SA MUST
be created with authentication other than NONE
or with AEAD cipher.
I think this falls under the non-IPTFS use case. I'd like to leave it out as it
would be confusing.
No, it's about any use case of this mechanism.
ESP can be used without authentication
(although it's strictly discouraged) and in this
if AGGFRAG is employed (regardless of IP-TFS),
then an attacker can re-order packets on his/her will,
by playing with SN field, so your reassembly mechanism won't work.
You think I need to state that things are not secure if the user turns off
authentication?
I think yes. You may have ESP SA w/o authentication, it's not
prohibited by RFC 4303.
In this case replay protection won't work (it may be OK for some
application).
What I want is to stress that AGGFRAG won't work either in this
situation.
Regards,
Valery.
I would think that's covered already by:
"
Other than
the additional security afforded by using this mechanism, IP-TFS
utilizes the security protocols [ <https://tools.ietf.org/html/rfc4303>
RFC4303] and [ <https://tools.ietf.org/html/rfc7296>
RFC7296] and so their
security considerations apply to IP-TFS as well.
"
Thanks,
Chris.
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
