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

From: Tom Pusateri <[email-masked]>
Date: Sun, 7 Mar 2010 23:50:36 -0500

I have taken the previous comments into account and added the AMT Membership Teardown message. The draft should be appearing shortly in the working group documents.

Something that occurred to me when writing this is that any node on the path between the gateway and the relay could spoof this new Membership Teardown message since they would know the original source address, source port, Nonce, and Response MAC. This does introduce a security weakness that didn't exist before.

Of course, maybe I misunderstood the solution and I created the problem. :)

I also made the UDP checksum required again for the AMT IP Multicast Data message as instructed by the working group chairs.

If any of the author addresses/contact info are out of date, please send me updates.

Thanks,
Tom

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 7 Mar 2010 21:40:42 -0800

> I have taken the previous comments into account and added the AMT  
> Membership Teardown message. The draft should be appearing shortly  
> in the working group documents.
>
> Something that occurred to me when writing this is that any node on  
> the path between the gateway and the relay could spoof this new  
> Membership Teardown message since they would know the original  
> source address, source port, Nonce, and Response MAC. This does  
> introduce a security weakness that didn't exist before.
>
> I also made the UDP checksum required again for the AMT IP Multicast  
> Data message as instructed by the working group chairs.

You mean for IPv6 only right?

Chairs, why did you do this? Shouldn't you have taken the same stance  
as the LISP working group?

Dino

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

---

From: Greg Shepherd <[email-masked]>
Date: Sun, 7 Mar 2010 22:04:33 -0800

On Sun, Mar 7, 2010 at 9:40 PM, Dino Farinacci <[email-masked]> wrote:
>> Membership Teardown message. The draft should be appearing shortly in the
>> working group documents.
>>
>> Something that occurred to me when writing this is that any node on the
>> path between the gateway and the relay could spoof this new Membership
>> Teardown message since they would know the original source address, source
>> port, Nonce, and Response MAC. This does introduce a security weakness that
>> didn't exist before.
>>
>> I also made the UDP checksum required again for the AMT IP Multicast Data
>> message as instructed by the working group chairs.
>
> Chairs, why did you do this? Shouldn't you have taken the same stance as the
> LISP working group?

What approach did LISP take?

Greg

> _______________________________________________
> MBONED mailing list
> [email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 7 Mar 2010 22:15:36 -0800

>>> Of course, maybe I misunderstood the solution and I created the  
>>> problem.
>>> :)
>>>

Here is the text when describing an IPv6 UDP checksum:

   UDP Checksum:  this field SHOULD be transmitted as zero by an ITR for
       either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS].   
When a
       packet with a zero UDP checksum is received by an ETR, the ETR
       MUST accept the packet for decapsulation.  When an ITR  
transmits a
       non-zero value for the UDP checksum, it MUST send a correctly
       computed value in this field.  When an ETR receives a packet with
       a non-zero UDP checksum, it MAY choose to verify the checksum
       value.  If it chooses to perform such verification, and the
       verification fails, the packet MUST be silently dropped.  If the
       ETR chooses not to perform the verification, or performs the
       verification successfully, the packet MUST be accepted for
       decapsulation.  The handling of UDP checksums for all tunneling
       protocols, including LISP, is under active discussion within the
       IETF.  When that discussion concludes, any necessary changes will
       be made to align LISP with the outcome of the broader discussion.

Dino

>
> Greg
>
>> Dino
>>
>>>
>>> If any of the author addresses/contact info are out of date,  
>>> please send
>>> me updates.
>>>
>>> Thanks,

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 8 Mar 2010 06:56:30 -0800

Thanks Dino!

Okay, I do think this would be best and would keep us inline with
parallel efforts like this such as LISP.

Greg

On Sun, Mar 7, 2010 at 10:15 PM, Dino Farinacci <[email-masked]> wrote:
>>>> Data
>      either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS].  When a
>      MUST accept the packet for decapsulation.  When an ITR transmits a

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 8 Mar 2010 10:05:36 -0500

This is essentially what we had before that caused us to stall. We'd  
like to end up there again but for now we're trying to see how far we  
can get in the standards process and what else might hold us up.

I'll save this text for later.

Tom

On Mar 8, 2010, at 9:56 AM, Greg Shepherd <[email-masked]> wrote:

>>>>> Membership Teardown message. The draft should be appearing  
>>>>> shortly in
>>>>> the
>>>>> working group documents.
>>>>>
>>>>> Teardown message since they would know the original source  
>>>>> address,
>>>>> source
>>>>> port, Nonce, and Response MAC. This does introduce a security  
>>>>> weakness
>>>>> that
>>>>> didn't exist before.
>>>>>
>>>> Chairs, why did you do this? Shouldn't you have taken the same  
>>>> stance as
>>>> the
>>>> LISP working group?
>>>

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 8 Mar 2010 07:13:34 -0800

I don't believe we had any text referencing the ongoing IETF work.

On Mon, Mar 8, 2010 at 7:05 AM, Tom Pusateri <[email-masked]> wrote:
> This is essentially what we had before that caused us to stall. We'd like to
> end up there again but for now we're trying to see how far we can get in the
> standards process and what else might hold us up.
>
>>>>> as
>>>>>> If any of the author addresses/contact info are out of date, please
>>>>>> send
>>>>>> me updates.
>>>>>>
>>>>>> Thanks,

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 8 Mar 2010 07:42:37 -0800

> parallel efforts like this such as LISP.

And compatible with hardware implementations of AMT.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 8 Mar 2010 07:47:01 -0800

If you decide to not revisit this Tom, then I would suggest indicating  
the issue is for IPv6 only rather than having the problem of  
contradicting RFC 768 for IPv4:

Dino

On Mar 8, 2010, at 7:05 AM, Tom Pusateri wrote:

> like to end up there again but for now we're trying to see how far  
> we can get in the standards process and what else might hold us up.
>

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 8 Mar 2010 11:01:37 -0500

Right. That was an oversight on my part in the change I made last night. We're only talking about IPv6.

Tom

On Mar 8, 2010, at 10:47 AM, Dino Farinacci wrote:

> If you decide to not revisit this Tom, then I would suggest indicating the issue is for IPv6 only rather than having the problem of contradicting RFC 768 for IPv4:
> 
> <Picture 2.png>
> 
> Dino
> 
>> This is essentially what we had before that caused us to stall. We'd like to end up there again but for now we're trying to see how far we can get in the standards process and what else might hold us up.
>>

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 8 Mar 2010 14:41:25 -0500

I'm totally for doing this on the list. I hit reply all. Not sure  
where the list got dropped off. If I did it, it was purely accidental.

My changes were based on Thalers comments and made sense to me.

My questions are:

1. If the source address is no longer on the gateway, then multicast  
data packets won't be delivered, so is bandwidth really an issue?

2. How quickly do you want to remove state in the relay?

Sorry for the confusion.

Tom

On Mar 8, 2010, at 2:15 PM, Dino Farinacci <[email-masked]> wrote:

>> I guess I'm not understanding the problem you're trying to solve.  
>> There really isn't the concept of a single tunnel. There's only  
>> data that comes at you based on membership reports. You either join  
>> or leave. It's basically IGMP over NBMA.
>
> There is a tunnel. The Discovery and Relay Advertisement exchange  
> creates state in the Relay. The Gateway knows that. The Gateway  
> wants to teardown and perhaps find a new Relay or use a new Gateway  
> address.
>
> Please keep the AT&T guys in the loop or else you are documenting  
> something they did not propose. I see we are having communication  
> issues with this.
>
> Why can't this all be discussed on the list?
>
> Dino
>
>>
>> Tom
>>
>> On Mar 8, 2010, at 1:55 PM, Dino Farinacci <[email-masked]> wrote:
>>
>>> Tom, that is not what we asked for. We want a "AMT Tunnel  
>>> Teardown" and not a "AMT Membership Teardown" message. If you put  
>>> a IGMP/MLD header in this then it is redundant with the "AMT  
>>> Update" that can signal leaving (S,G) entries.
>>>
>>> Dino
>>>
>>> On Mar 8, 2010, at 8:20 AM, Tom Pusateri wrote:
>>>
>>>> Its in the repository. You can get a diff from here:
>>>>
>>>> http://tools.ietf.org/wg/mboned/draft-ietf-mboned-auto-multicast/
>>>>
>>>> Tom
>>>>
>>>> On Mar 8, 2010, at 11:15 AM, Dino Farinacci wrote:
>>>>
>>>>> I didn't see the draft. Have you not sent it yet?
>>>>>
>>>>> Can you send diffs?
>>>>>
>>>>> Dino
>>>>>
>>>>> On Mar 8, 2010, at 8:01 AM, Tom Pusateri wrote:
>>>>>
>>>>>> Right. That was an oversight on my part in the change I made  
>>>>>> last night. We're only talking about IPv6.
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>>> If you decide to not revisit this Tom, then I would suggest  
>>>>>>> indicating the issue is for IPv6 only rather than having the  
>>>>>>> problem of contradicting RFC 768 for IPv4:
>>>>>>>
>>>>>>> <Picture 2.png>
>>>>>>>
>>>>>>> Dino
>>>>>>>
>>>>>>>> This is essentially what we had before that caused us to  
>>>>>>>> stall. We'd like to end up there again but for now we're  
>>>>>>>> trying to see how far we can get in the standards process and  
>>>>>>>> what else might hold us up.
>>>>>>>>
>>>>>>>>> On Sun, Mar 7, 2010 at 10:15 PM, Dino Farinacci <[email-masked] 
>>>>>>>>> > wrote:
>>>>>>>>>>> On Sun, Mar 7, 2010 at 9:40 PM, Dino Farinacci <[email-masked] 
>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Membership Teardown message. The draft should be  
>>>>>>>>>>>>> appearing shortly in
>>>>>>>>>>>>> the
>>>>>>>>>>>>> working group documents.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Teardown message since they would know the original  
>>>>>>>>>>>>> source address,
>>>>>>>>>>>>> source
>>>>>>>>>>>>> port, Nonce, and Response MAC. This does introduce a  
>>>>>>>>>>>>> security weakness
>>>>>>>>>>>>> that
>>>>>>>>>>>>> didn't exist before.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Of course, maybe I misunderstood the solution and I  
>>>>>>>>>>>>> created the problem.
>>>>>>>>>>>>> :)
>>>>>>>>>>>>>
>>>>>>>>>>>> Chairs, why did you do this? Shouldn't you have taken the  
>>>>>>>>>>>> same stance as
>>>>>>>>>>>> the
>>>>>>>>>>>> LISP working group?
>>>>>>>>>>>
>>>>>>>>>>>>> If any of the author addresses/contact info are out of  
>>>>>>>>>>>>> date, please send
>>>>>>>>>>>>> me updates.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 8 Mar 2010 11:44:27 -0800

On Mon, Mar 8, 2010 at 11:41 AM, Tom Pusateri <[email-masked]> wrote:
> I'm totally for doing this on the list. I hit reply all. Not sure where the
> list got dropped off. If I did it, it was purely accidental.
>
> 1. If the source address is no longer on the gateway, then multicast data
> packets won't be delivered, so is bandwidth really an issue?

The packets will continue until the Relay state times out. So yes,
bandwidth is an issue. BTW, this request came from operators. Remember
when the IETF solutions were directed at solving operator needs?
;-);-)

> 2. How quickly do you want to remove state in the relay?

As quickly as possible.

Greg

>>> I guess I'm not understanding the problem you're trying to solve. There
>>> really isn't the concept of a single tunnel. There's only data that comes at
>>> you based on membership reports. You either join or leave. It's basically
>>> IGMP over NBMA.
>>
>> There is a tunnel. The Discovery and Relay Advertisement exchange creates
>> state in the Relay. The Gateway knows that. The Gateway wants to teardown
>> and perhaps find a new Relay or use a new Gateway address.
>>
>> something they did not propose. I see we are having communication issues
>> with this.
>>
>>>> Tom, that is not what we asked for. We want a "AMT Tunnel Teardown" and
>>>> not a "AMT Membership Teardown" message. If you put a IGMP/MLD header in
>>>> this then it is redundant with the "AMT Update" that can signal leaving
>>>> (S,G) entries.
>>>>
>>>> Dino
>>>>
>>>>>>>> indicating the issue is for IPv6 only rather than having the problem of
>>>>>>>>> This is essentially what we had before that caused us to stall.
>>>>>>>>> We'd like to end up there again but for now we're trying to see how far we
>>>>>>>>>>>>>> Of course, maybe I misunderstood the solution and I created
>>>>>>>>>>>>>> the problem.
>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 8 Mar 2010 15:09:54 -0500

> when the IETF solutions were directed at solving operator needs?

You are being too vague. Maybe it would help if you describe some specific scenarios instead of everyone trying to guess what your problem is. At the gateway? At the relay? What happens at the gateway that causes this situation?  What does the network around the gateway look like and what changes take place? I'm having to guess at everything?

I think we're all trying to solve the needs of operators. But that doesn't mean we can't try to keep the architectural purity we've maintained up to this point.

>> 2. How quickly do you want to remove state in the relay?

That is not helpful.

Thanks,
Tom

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 8 Mar 2010 17:05:04 -0500

How far can you get by adjusting the querier interval? 1s?

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 8 Mar 2010 18:35:34 -0800

> where the list got dropped off. If I did it, it was purely accidental.

I pruned it when I wanted to ask you if you had posted it. So sorry  
for that.

> My changes were based on Thalers comments and made sense to me.

Yes, but you didn't get consensus on that. That is the part I thought  
should have been on the list.

We need to listen to the AT&T guys. The requirement was to have a  
"Tunnel Teardown" not multicast state tear-down. That is already there  
with an AMT Update message. The Tunnel Teardown is suppose to remove  
all multicast state associated with the tunnel *as well as* the tunnel  
specific state in the Relay.

> data packets won't be delivered, so is bandwidth really an issue?

Yes, because if the gateway changes addresses and is sitting behind a  
slow link, and then joins to a new Relay, it will get double data for  
some period of time. In my implementation, that could be as long as 10  
minutes.

> 2. How quickly do you want to remove state in the relay?

As soon as the authenticated Gateway wants to.

Dino

>>> data that comes at you based on membership reports. You either  
>>> join or leave. It's basically IGMP over NBMA.
>>
>>>>>>>>> trying to see how far we can get in the standards process  
>>>>>>>>> and what else might hold us up.
>>>>>>>>>
>>>>>>>>>>>>> Chairs, why did you do this? Shouldn't you have taken  
>>>>>>>>>>>>> the same stance as
>>>>>>>>>>>>> the
>>>>>>>>>>>>> LISP working group?
>>>>>>>>>>>>

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 8 Mar 2010 20:17:55 -0800

> How far can you get by adjusting the querier interval? 1s?

Using the quierier interval in this way seriously impacts control
plane scaling of the Relay.

Greg