RE: IPsec & Markers

I agree with Caitlin.

The receiver already has all the flexibility it needs.  If it doesn't want markers, for whatever reason, it just clears the flag in the MPA Req/Rep message.  There is no reason to hash out the receivers reasons for not wanting markers.

--jc

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On Behalf Of
> Caitlin Bestler
> Sent: Tuesday, October 12, 2004 9:13 AM
> To: Sukanta ganguly
> Cc: Somesh Gupta; Black; [email protected]
> Subject: RE: [rddp] 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/
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp
>