Re: Re: [ssm] SSM with IPSec

I agree with you, and I didn't mean to imply that this was an SSM-only
problem.  NTP is a good example of an ASM app that has the same
problem.  The fact that this problem occurs with ASM is a complicating
factor in determining the right solution (which is a major reason that
I don't want to tackle it in SSM).

I think it would be relatively easy to specify IPSec modifications to
fix the SSM problem.  But to solve the ASM problem you have to do
source-based SAD lookups in some cases for ASM addresses.  There are
some design choices to consider in how to specify the SAD lookups and
some and backwards compatibility issues that need to be worked out to
solve the ASM problem, or so I am told.

Given that the tricky issues arise mostly from ASM and that msec has
the ipsec expertise and the charter, I think it makes sense to solve
this in msec rather than in ssm.  Sounds like you agree with that
anyway..

I'll find out where msec is at in terms of solving this problem and
report back.

-Hugh

> Cc: ssm@ietf.org, mbaugher@cisco.com, bew@cisco.com
> Date: Wed, 15 Jan 2003 08:57:05 -0700
> From: Brad Huntting <huntting@glarp.com>
> 
> 
> > The solution that I most like is fairly easy to state: require the
> > source address to be part of the SA lookup when the destination
> > address is an SSM address.  Mark and Brian inform me that the msec
> > working group is looking at solving the problem this way.
> 
> What if the destination address is not in the SSM range?  For
> example: A host wishes to receive NTP (network time protocol)
> multicast traffic (destination address 224.0.1.1) from three specific
> hosts that it trusts (whether PIM-SSM can honor this request
> efficiently is, I think, a separate issue).  I assume there is no
> global group `owner' for this well known address 224.0.1.1, so the
> SA for this traffic would, I suspect, need to be indexed by source
> and destination just like SSM.
> 
> One could easily imagine similar situations for other group addresses.
> However, as you pointed out, it's probably not necessary that the
> SSM group solve this problem; at least not right away.
> 
> 
> brad
> _______________________________________________
> ssm mailing list
> ssm@ietf.org
> https://www1.ietf.org/mailman/listinfo/ssm

_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm