RE: IPsec & Markers

Sukanta ganguly said:
> Hi,
>   Do we need another draft for finalizing the IPSec &
> Marker discussion. We have had a lot of discussion but
> seems like no conclusion is beingh made. We keep on
> revisiting this topic multiple times.
>   It definitely is time to  put a formal, agreeable
> statement resolving this issue so that we can all
> conclude happily.
>
> Thanks
> SG
>

If a bit were worth adding, it would have the following
meaning:

1) The side setting the bit has an MPA-Aware IPSEC
   implementation.  Hence each IP Datagram submitted
   to IPSEC for this connection would contain only
   whole MPA Frames.
2) That in its interface with the local IPSEC stack
   it will be aware of the original TCP Segment boundaries,
   and that nothing in the local stack will disturb them.
3) That if this bit is set by the other side, then this
   side does not want Markers sent to it.

The last point in particular strikes me as unlikely.
If your peer does not have MPA thru IPSEC tightly
integrated you will want markers.  Therefore you have
to have the logic to process them.

This is a major contrast with the normal marker suppression,
which is intended to support receivers who did not want to
deal with Markers at all.

Markers are ugly, and they add code/gate complexity.  But
they aren't all that computationally intensive.  If you have
the code/gates to implement them, and you even have number
crunching capacity to intergrate IPSEC, then why do you need
to suppress receiving markers *if* and only if an "alignment-
maintaing IPSEC tunnel" can be validated to exist?

The sender already MUST support generating or not generating
them.  The existing bit was justified by allowing some
implementations to totally avoid processing markers on
receive when they in fact had no use for them.

But using up another option bit for this just doesn't
strike me as worthwhile.  You do run out of them eventually.


--
Caitlin Bestler
http://asomi.com/