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

On Jul 17, 2007, at 2:36 AM, Stig Venaas wrote:

> 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.
>

Note that in any case, the S is modified, and thus the outside SDP  
files etc. have to be too.

> 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).

Thinking about this overnight, this seems to me to be a lot like port  
mapping in a NAT.

If you have a simple NAT (i.e., where all internal addresses go to  
one external one), and you make sure that
your SSM groups are all distinct, you can announce a SSM channel  
sourced from the inside.
(Note that you still have to be knowledgeable enough to know your  
external IP address, which would
weed out many home users.)

If you want to use two SSM channels with the same group (maybe it's  
built into your handy SSM enabled video
camera, and you have two of them), then it becomes like port mapping  
- presumably there will be a table
in the NAT where you can set this
up. You will almost certainly have to know what you are doing for  
this to work.

Note that if there is more than one external S address for the NAT to  
pick from, you have a similar problem. (It's
not enough just to get a new source address - the content source has  
to know what it is.)

So, I think that it would be adequate to take Stig's solution, with  
something like "the NAT MAY provide additional means, such as mapping  
tables, to allow the NAT user to manage the mapping of sources,  
groups and ports of SSM transmissions."

Regards
Marshall

>
> 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
>
>
>
> _______________________________________________
> MBONED mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/mboned