Subject: [MBONED] Addt'l Comments on draft-ietf-mboned-auto-multicast-10.txt

From: "MCCRINK, PATRICIA E (ATTLABS)" <[email-masked]>
Date: Wed, 10 Mar 2010 15:08:44 -0500

Tom, et. al.,

We have some additional comments on the latest AMT Draft ver 10.

1)      Section 6.7

a.       This is not exactly what we proposed.   Given intent is to
teardown entire tunnel, should not need to enumerate all the groups in a
leave statement.

2)      Section 6.2

a.       Need modified Advertisement message so Relay can pass back to
the GW the GW's source/port that it is known by.   This is critical if
GW is behind NAT device (e.g. broadband modem or home router).   This
was proposed already to the mailing list:
http://www.ietf.org/mail-archive/web/mboned/current/msg00952.html

3)      The wording in the AMT Draft should be tightened up to eliminate
confusion among implementers about when Discovery is required.
Suggested changes:

a.       Section 5.1.3, 2nd bullet:
FROM - "The AMT Relay Discovery message can be sent on demand if no
relay is known at this time or at startup and be periodically
refreshed."  
TO - "The AMT Relay Discovery message should be sent every time the
Gateway is establishing a new tunnel (first join) and may be
periodically refreshed."

b.      Section  7.1:
FROM - "It can send an AMT Relay Discovery at startup time or wait until
it has a group membership to report"
TO - "It should send an AMT Relay Discovery whenever it is establishing
a new tunnel (i.e. has no existing joins and needs to report a new group
membership)."

4)      Section 4.6

a.       Add statement "An AMT Relay anycast prefix may also provided as
a /32 (IPV4) or /128 (IPV6), in which case no manipulation is required
to determine the anycast address."

5)      Section 6.3

a.       The statement "The UDP source port is uniquely selected by the
local host operating system.   It can be different for each Request and
different from the source port used in Discovery messages but does not
have to be" implies that the Relay can uniquely identify each GW based
on the IP address alone.   However, multiple GWs may reside on a PC
behind a NAT device (e.g. broadband modem, home router) - in this case,
it is critical that the Relay identify the GWs by address and port and
the port used by a particular GW must remain constant for the duration
of an established tunnel to the Relay.     

We suggest the following change:
"The UDP source port is uniquely selected by the local host operating
system.   In order to support multiple Gateways behind a NAT device
(e.g. broadband modem, home router) it is essential that the Relay
identify the Gateways by address and port.  As a result, the UDP source
port used by a particular Gateway must remain constant for the duration
of the tunnel to the Relay.  This includes the Relay Discovery message
as well as all AMT Request and Membership Update messages.  

Sincerely,

Mark Altom

Andy Huang

Tom Imburgia

Pat McCrink

Han Nguyen

Doug Nortz

AT&T Labs

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 10 Mar 2010 15:37:31 -0500

On Mar 10, 2010, at 3:08 PM, MCCRINK, PATRICIA E (ATTLABS) wrote:

> a.       This is not exactly what we proposed.   Given intent is to teardown entire tunnel, should not need to enumerate all the groups in a leave statement.

I read your proposal and merged it with Dave Thaler's comments. AMT is providing an NBMA IGMP/MLD service and we were trying to stick with the model that the relay just processes remote IGMP/MLD commands. I didn't like the way it ended up in the draft either but the deadline was looming and so I published it so we could have a discussion point. Dino voiced the same opinion as you did.

However, the security isn't sufficient for a single teardown. I was hoping that by cranking down the IGMP Query Interval, we could avoid the whole problem. That is why I was probing for more information about the address loss detection time. Its not uncommon in walled gardens to crank the Query Interval down to 1 second.

> 
> 2)      Section 6.2
> a.       Need modified Advertisement message so Relay can pass back to the GW the GW’s source/port that it is known by.   This is critical if GW is behind NAT device (e.g. broadband modem or home router).   This was proposed already to the mailing list:

Yes, this is another can of worms with adding the original source port and source address. I would rather just not put addresses or ports in to begin with.

We need to rethink the whole solution to achieve the needed security concerns.

Maybe the gateway can just send keepalives.

I'll go over these other wording changes later.

Thanks,
Tom

> 3)      The wording in the AMT Draft should be tightened up to eliminate confusion among implementers about when Discovery is required.   Suggested changes:
> FROM - “The AMT Relay Discovery message can be sent on demand if no relay is known at this time or at startup and be periodically refreshed.”  
> TO – “The AMT Relay Discovery message should be sent every time the Gateway is establishing a new tunnel (first join) and may be periodically refreshed.”
> b.      Section  7.1:
> FROM – “It can send an AMT Relay Discovery at startup time or wait until it has a group membership to report”
> TO – “It should send an AMT Relay Discovery whenever it is establishing a new tunnel (i.e. has no existing joins and needs to report a new group membership).”
> 
> 4)      Section 4.6
> a.       Add statement “An AMT Relay anycast prefix may also provided as a /32 (IPV4) or /128 (IPV6), in which case no manipulation is required to determine the anycast address.”
> 
> 5)      Section 6.3
> a.       The statement “The UDP source port is uniquely selected by the local host operating system.   It can be different for each Request and different from the source port used in Discovery messages but does not have to be” implies that the Relay can uniquely identify each GW based on the IP address alone.   However, multiple GWs may reside on a PC behind a NAT device (e.g. broadband modem, home router) – in this case, it is critical that the Relay identify the GWs by address and port and the port used by a particular GW must remain constant for the duration of an established tunnel to the Relay.    
> 
> “The UDP source port is uniquely selected by the local host operating system.   In order to support multiple Gateways behind a NAT device (e.g. broadband modem, home router) it is essential that the Relay identify the Gateways by address and port.  As a result, the UDP source port used by a particular Gateway must remain constant for the duration of the tunnel to the Relay.  This includes the Relay Discovery message as well as all AMT Request and Membership Update messages.  
>  
> Sincerely,
>  
> Mark Altom
> Andy Huang
> Tom Imburgia
> Pat McCrink
> Han Nguyen
> Doug Nortz
> AT&T Labs
>  
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 10 Mar 2010 16:15:13 -0800

> However, the security isn't sufficient for a single teardown. I was  
> hoping that by cranking down the IGMP Query Interval, we could avoid  
> the whole problem. That is why I was probing for more information  
> about the address loss detection time. Its not uncommon in walled  
> gardens to crank the Query Interval down to 1 second.

Can you say why?

If it is sufficient for AMT Update messages why wouldn't it be for  
Tunnel Teardown messages?

Dino

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 10 Mar 2010 19:21:05 -0500

On Mar 10, 2010, at 7:15 PM, Dino Farinacci wrote:

> If it is sufficient for AMT Update messages why wouldn't it be for Tunnel Teardown messages?
> 
> Dino
> 

Sure. The other AMT messages come from the source address which is hashed in the Response MAC. When you change the source address, you lose all the security.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 10 Mar 2010 16:22:29 -0800

>>> However, the security isn't sufficient for a single teardown. I  
>>> was hoping that by cranking down the IGMP Query Interval, we could  
>>> avoid the whole problem. That is why I was probing for more  
>>> information about the address loss detection time. Its not  
>>> uncommon in walled gardens to crank the Query Interval down to 1  
>>> second.
>>
>> Can you say why?
>>
> Sure. The other AMT messages come from the source address which is  
> hashed in the Response MAC. When you change the source address, you  
> lose all the security.
>
> Tom

The proposal was to send the Tunnel Teardown from the old address I  
believe.

Dino

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 10 Mar 2010 19:28:02 -0500

On Mar 10, 2010, at 7:22 PM, Dino Farinacci wrote:

> The proposal was to send the Tunnel Teardown from the old address I believe.
> 
> Dino
> 

It wasn't clear to me that faking the source address was the proposal. There would be no need to include the source port and source address in the packet and deal with NAT if that were the case but the proposal from the AT&T guys clearly had added these fields.

Source spoofing may work in some scenarios and not others depending on how the source address is changing and if uRPF filters are going to prevent it.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 10 Mar 2010 16:33:00 -0800

>>>>> was hoping that by cranking down the IGMP Query Interval, we  
>>>>> could avoid the whole problem. That is why I was probing for  
>>>>> more information about the address loss detection time. Its not  
>>> hashed in the Response MAC. When you change the source address,  
>>> you lose all the security.
>>>
>>> Tom
>>
> It wasn't clear to me that faking the source address was the  
> proposal. There would be no need to include the source port and  
> source address in the packet and deal with NAT if that were the case  
> but the proposal from the AT&T guys clearly had added these fields.

It isn't faking it but your point is weak. Anyone can put in any  
source address even the valid one that the Relay has cached.

It is the Response MAC that provides the security. So all this is a  
moot point.

Dino

> Source spoofing may work in some scenarios and not others depending  
> on how the source address is changing and if uRPF filters are going  
> to prevent it.
>
> Tom
>

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 10 Mar 2010 19:39:09 -0500

On Mar 10, 2010, at 7:33 PM, Dino Farinacci <[email-masked]> wrote:

>>>>>> uncommon in walled gardens to crank the Query Interval down to  
>>>>>> 1 second.
>>>>>
>>>>> Can you say why?
>>>>>
>>>> Sure. The other AMT messages come from the source address which  
>>>> is hashed in the Response MAC. When you change the source  
>>>> address, you lose all the security.
>>>>
>>>> Tom
>>>
>> source address in the packet and deal with NAT if that were the  
>> case but the proposal from the AT&T guys clearly had added these  
>> fields.
>

Actually, because the gateway could be behind a nat, this won't work.  
You don't even know what source address ended up at the relay.

I have an idea using public / private keys that will work but it  
changes a lot.

I'll try to summarize the pros and cons of all the options and write  
this up tonight after dinner.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 10 Mar 2010 16:43:11 -0800

> Actually, because the gateway could be behind a nat, this won't  
> work. You don't even know what source address ended up at the relay.
>

Why can't we just stay with the Response MAC and the query nonce?

Why are we making this harder?

Dino

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 10 Mar 2010 19:57:51 -0500

On Mar 10, 2010, at 7:43 PM, Dino Farinacci <[email-masked]> wrote:

>> I'll try to summarize the pros and cons of all the options and  
>> write this up tonight after dinner.
>

If the source address changes, it will most certainly change the  
source port on an upstream nat box which means the response MAC will  
be useless.

Tom

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 10 Mar 2010 20:36:33 -0500

> source port on an upstream nat box which means the response MAC will  

Sorry, you said you're going to use the same source address and port  
but you're sending it out a different interface. So, the chances of  
going through a different NAT are good and that would cause the source  
address and port to change from the relay's perspective.

So it would work in some cases and not in others. But if you're happy  
with that, then we don't need any spec changes, you can just implement  
that way.

If we want to be able to handle all the NAT cases, then we'll have to  
change things to either interact with the NAT or use encryption  
technology and don't base the response MAC on addresses and ports at  
all.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 10 Mar 2010 17:36:41 -0800

> source port on an upstream nat box which means the response MAC will  

So you are concluding that AMT gateways can't be behind NATs? Because  
if they were today then AMT Updates wouldn't work?

The MAC is computed by the Relay based on its idea of the gateway IP  
address and port number. The Gateway just echos this back in a AMT  
Update. All that is being proposed is that the Gateway echo back the  
last MAC the Relay sent it.

This can work even when the gateway IP address changes.

So I am not groking what you think the problem is.

Dino

---

From: "MCCRINK, PATRICIA E (ATTLABS)" <[email-masked]>
Date: Thu, 11 Mar 2010 12:26:09 -0500

Some clarification on the proposal for new Teardown Message and modified
Advertisement Message:

Problem Description:

A typical scenario for an AMT GW is that it will reside on a PC behind a
NAT device (e.g. broadband modem/router and/or home router).   The
broadband bandwidth available varies significantly between users and
over time.   

The problem that we are attempting to solve is to reduce/eliminate
duplicate streams sent to the NAT device in the case when the PC's local
interface is interrupted, which may result in the NAT port changing.
For example, this could happen if the user switches from a wired to a
Wifi connection.   It is possible that this change could also result in
the NAT IP address changing (e.g. if switches to a different NAT device
or if local interface got interrupted due to a reboot of the NAT
device).   However, it is also possible that the NAT IP address may stay
constant.

The GW can detect a local interface interruption and start the
Discovery, and 3-way handshake with the same (or a new) Relay.   At the
same time, the old Relay will stop receiving the 3-way handshakes from
the old address/port and can eventually time out this old GW.   However,
during this time period, it is possible that the end user will be
receiving duplicate streams down to their NAT device.  Given that
broadband links are often congested and this is UDP traffic, the
experience for the end user will be degraded until the Relay times out
the old GW.

Proposed Solution:

Since the GW is aware of the local interface interruption, it can inform
its old Relay to stop forwarding packets by using the proposed Teardown
message, thereby eliminating duplicate streams to the NAT device.   The
proposed method has the GW using its current address/port as the source
and including the old source address/port within the body of the
message.

It is true that the NAT device can also change its public IP address
without interrupting the local interface (and therefore without the GW
noticing).   In this case, since the GW is unaware of change, it cannot
send the Teardown message.   The Relay may send a duplicate stream until
it times out the old GW.   However, in this case, the duplicate stream
will not get routed to the NAT device since it has changed its address
and will likely get Null routed by the ISPs upstream router.
Therefore, from a user-perspective, this does not degrade performance
and does not fall into the problem that we are attempting to solve.

Requirements of Solution:

Any workable solution:
* work with legacy broadband modem/router, home routers, etc.   
* must not significantly increase processing required by GW (PC)
* must be scalable in Relay
* should be secure to the extent possible

Sincerely,

Mark Altom
Andy Huang
Tom Imburgia
Pat McCrink
Han Nguyen
Doug Nortz
AT&T Labs