Re: [MBONED] multiple SSM sources behind a NAT

Bharat Joshi <[email protected]> Tue, 17 Jul 2007 11:34:35 +0530
Newsgroups gmane.ietf.magma,gmane.ietf.nat.behave
Organization Infosys Technologies Ltd
Message-ID <1184652275.14104.83.camel@magadha>
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.
> 
>     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***