Subject: [magma] multiple SSM sources behind a NAT

From: "Dan Wing" <[email-masked]>
Date: Mon, 16 Jul 2007 18:14:37 -0700

During some offline discussions, Prashant Jhingran brought up an issue
we aren't sure how to best resolve.

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

Comments and additional suggestions are welcome.

-d

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 16 Jul 2007 22:09:00 -0400

Hello;

>      192.168.1.1      | NAT +------------- Internet

Why not change the SSM group, say by incrementing the second address  
by one until it is unique.

- On the outside of the NAT, the SSM channel will be unique,  
regardless of what G is chosen.
- I can't think of a multicast situation where the inside and outside  
of the NAT will communicate about
this.
- In either case, the source cannot easily communicate the channel  
address, as you are changing the S address
anyway. Given that, it is not clear how much use we can expect of SSM  
broadcasts from within the NAT to outside.

Regards
Marshall

> MBONED mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mboned

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 17 Jul 2007 11:34:35 +0530

Dan,

>      192.168.1.1      | NAT +------------- Internet

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

---

From: Stig Venaas <[email-masked]>
Date: Tue, 17 Jul 2007 08:36:24 +0200

>>      192.168.1.1      | NAT +------------- Internet

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

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 17 Jul 2007 07:07:00 -0400

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

> 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

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

---

From: Beau Williamson <[email-masked]>
Date: Tue, 17 Jul 2007 08:27:53 -0500

>different MAC addresses due to snooping devices and NICs).

I agree with Stig on this.  I don't think we want to tackle this 
problem.  If you have multiple SSM sources behind a NAT, there are 
other ways to solve this such as above or the best way (IMHO) is to 
get more global addresses from your SP so your SSM sources can each 
have a unique global address.   I know this isn't always easily done 
but I still don't think we want to solve this problem for 
administrators by coming up with special NAT GW behaviors.

Beau Williamson

---

From: "Alvaro Fernandez" <[email-masked]>
Date: Tue, 17 Jul 2007 15:34:07 +0200

Hello:
 
Lasth month we were disussing the same and I made the same proposal as Marshall: change the multicast group, but there is necesary some mechanism to inform of this change to multicast receivers. I think this is the problem.
This is an extract from the discussion of last month:

Alvaro Fernandez wrote:
> Brian:
>
>
> It is an idea regarding the BEHAVE Internet Draft and how the multicast
> NAPT can allow outside multicast routers to uniquely identify different
> multicast SSM channels (S,G) coming from inside interfaces in the case
> two inside interfaces use the same multicast group.
>

How prevalent do people expect the scenario of a SSM sender being
located behind a NAPT?

> 
>
> In the BEHAVE draft, REQ-4, if there is a host on the inside interface
> sending UDP packets to a multicast group, the NAPT can change the source
> address and the port but not the multicast group address. In this way, I
> think the outside routers can not differentiate the two channels because
> they have the same source (the public interface) and the same multicast
> group address.
>

Is it possible for the NAPT to have multiple external addresses to use
as source addresses?

> 
>
> Allowing the NAPT to change the multicast group address in the case two
> sender behind the NAPT use the same group address in a similar way the
> NATP changes a UDP port is a possible solution. There are other
> possibilities.

>From the global perspective, how does a receiver outside the NAPT know
the (S,G) combination to join?

Regards,
Brian

________________________________

De: Marshall Eubanks [mailto:[email-masked]]
Enviado el: mar 17/07/2007 4:09
Para: Dan Wing
CC: [email-masked]; [email-masked]
Asunto: Re: [MBONED] multiple SSM sources behind a NAT

Hello;

Regards
Marshall

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 17 Jul 2007 10:06:04 -0400

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]] 
 
>      192.168.1.1      | NAT +------------- Internet

My assumption was always that the only NAT readily usable for this
scenario would be a 1:1 NAT. In other words, a NAT, not a NAPT.

Bert

---

From: "Alvaro Fernandez" <[email-masked]>
Date: Tue, 17 Jul 2007 23:17:40 +0200

Hello,

A very simple solution:

Multicast senders can choose the multicast group from 224.0.0.0 to 239.255.255.255.

A simple solution is to recommend (ietf draft) multicast sender to use groups in the form: xxx.yyy.zzz.xxx where the user can choose x and

1)      yyy.zzz are the last two bytes of the internal IP address. (for example 192.168.yyy.zzz)

Or another solution (when using more than one NAPT):

2)      yyy is the last byte of the internal IP address and zzz is the public IP address.

note that SSM range is shorter than ASM.

Regards

Alvaro

De: Beau Williamson [mailto:[email-masked]]
Enviado el: mar 17/07/2007 15:27
Para: Stig Venaas; Bharat Joshi
CC: [email-masked]; [email-masked]; [email-masked]
Asunto: [BEHAVE] Re: [magma] Re: [MBONED] multiple SSM sources behind a NAT

Beau Williamson 

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave