Re: Re: [MBONED] multiple SSM sources behind a NAT

Bharat Joshi wrote:
> Dan,
> 
>> The problem is that if two (or more) SSM sources are on the 'inside'
>> of a NAT, they can choose the same multicast IP address (G).  This
>> works fine on the 'inside' of the NAT -- they are distinguished
>> because their SSM channel is unique because they have different
>> source IP addresses (S).  However, if their traffic is NATted, they
>> will share the same IP source address on the Internet, as in the
>> following diagram:
>>
>>                       +-----+
>>     SSM source A -----+     |
>>      192.168.1.1      | NAT +------------- Internet
>>                       |     |192.0.2.1
>>     SSM source B -----+     |
>>      192.168.1.2      +-----+
>>
>>
>> There seems to be only one viable approach to address this problem:
>>
>> First SSM source wins and new SSM source loses.  That is, when the
>> number of SSM sources exceeds the number of public IP interfaces, the
>> first SSM source(s) win, and the newest SSM source loses.  That is,
>> the newest SSM source's traffic is not forwarded towards the public
>> interface.

This sounds rather ugly to me, and the behaviour may be hard to
understand for users exposed to this. I would rather have both
being forwarded and say that it's a user error to try to use the
same group for the two. That is like Marshall said, use different
groups. However, I don't think it's a good idea to modify the group
in the NAT itself since that would also probably require the
announcement of which S,G to be used to be modified, and this can be
done through methods, e.g. SDP file through HTTP or email or whatever.

In short, I don't think you should solve this. In this not so common
situation, better let admins/users figure out that they should not
use the same G. In fact, there may be other reasons for choosing
different Gs as well (e.g. it may be good to use Gs that map to
different MAC addresses due to snooping devices and NICs).

Stig

>>
>>     Difficulties:
>>
>>     - NAT can't detect that first SSM source has finished sending and
>>       the block should be removed, except with a timeout.  How long
>>       should we recommend for that timeout?
>>
>>     - We can't communicate to the losing SSM source that its SSM data
>>       isn't being forwarded by the NAT.
>>
>>     - Do we want to RECOMMEND that a NAT allow the NAT administrator
>>       to override this behavior, and transmit multicast packets
>>       without regard to this problem?  (This is functionally the same
>>       as using a timeout of 0ms).
>>
> 
> First of all, for SSM, receives MUST know the source address so that
> they can subscribe to the SSM channel [A given S,G pair]. In the first
> place, I would say that this would be a wrong configuration.
> 
> If someone wants to support this and gateway does NAT, NAT device could
> change the group address to something different. But there should be a
> way for receivers to find out what group address NAT device chooses for
> a given stream.
> 
> Not allowing a second stream destined to same SSM group looks fine.
> 
> I am not sure if receivers can differentiate the streams based on the
> destination port [if stream is destined for one] but this will not work
> if the hosts inside NAT uses the same destination port also.
> 
> My 2 cents.
> 
> Thanks,
> Bharat
> 
> 
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
> 
> _______________________________________________
> magma mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/magma