Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-mstp-solution

From: Jari Arkko <[email-masked]>
Date: Sat, 12 Jul 2008 00:27:38 -0400

I have reviewed the updated draft (thanks for the update!), and compared 
it to my earlier comments and Gorry's review comments.

Most of the problems were corrected. The remaining parts seem easy to 
address, perhaps you could even do it before the I-D deadline on Monday. 
Here's what remains:

In Gorry's review he pointed out that the UDP usage guidelines document 
recommends an exponential back-off mechanism. The mstp draft deviates 
from this, and I'm not sure its appropriate to do so. Note that the 
guidelines had only a recommendation, not a requirement. But its not 
clear that you actually want to avoid an exponential back-off. Its easy 
to think of situations (such as the base station going down) where there 
would be a significant amount of retransmission traffic from a large 
number of hosts.

Section 5.3 talks about "step c" which I no longer can find.

I would like to see Appendix A removed; for the reasons discussed 
earlier the relay approach has problems. I don't think we want to 
publish a spec that hints that the relay approach should be done.

I did not notice changes relating to the following:

> MIH Transport Options
>   
>
> The document does not talk about how servers know the capabilities of
> clients that send event/command services to. Is this a part of the IEEE
> definitions, and you subscribe to a particular event stream? In any
> case, the document should talk about this and point to the relevant
> other specifications where needed.
>
>   
>> >    In the case where DHCP is used for node discovery and authentication
>> >    of the source and content of DHCP messages is required, network
>> >    administrators SHOULD use DHCP authentication option described in
>> >    [RFC3118 <http://tools.ietf.org/html/rfc3118>], where available or rely upon link layer security.  This
>> >    will also protect the DHCP server against denial of service attacks
>> >    to.  [RFC3118 <http://tools.ietf.org/html/rfc3118>] provides mechanisms for both entity authentication and
>> >    message authentication.
>>     
>
> I think the overall recommendation is good, but practically no one is
> going to deploy RFC 3118. With this in mind, I would like to see the
> above paragraph explain in more detail the security implications of
> relying on link layer security.
>   

Jari

_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Sat, 12 Jul 2008 01:49:15 -0400

Hi Jari,

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jari Arkko
> Sent: Friday, July 11, 2008 9:28 PM
> To: Telemaco Melia (tmelia)
> Cc: [email-masked]; 
> [email-masked]; Mipshop
> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-mstp-solution

> publish a spec that hints that the relay approach should be done.

I think we need a little bit more discussion on this before removing it.
Personally, I would like to hear from folks who participated in the
design team. I also want to figure out what exactly 3GPP wants in this
space for their ANDSF feature.

I also want to chat with Vivek (.21 chair) to see if they care about
this scenario.

It might be premature to remove this. 

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Sat, 12 Jul 2008 07:09:01 -0400

Vijay,

> I think we need a little bit more discussion on this before removing it.
OK, but I take it that this discussion applies to the entire issue, and 
not just the appendix question. If we were to support relay-based 
discovery after the discussion, Appendix A wouldn't be sufficient. I was 
commenting on this on the assumption that the authors agreed with the 
issue that I raised, since the actual support was removed. If we still 
need to talk about that, that's fine. I would be very interested to hear 
more .21 and 3GPP viewpoints on this.

Jari

---

From: "Telemaco Melia (tmelia)" <[email-masked]>
Date: Wed, 23 Jul 2008 17:07:16 +0200

Hi Jari,

Please see comments below. 

[SNIP]
In Gorry's review he pointed out that the UDP usage guidelines document
recommends an exponential back-off mechanism. The mstp draft deviates
from this, and I'm not sure its appropriate to do so. Note that the
guidelines had only a recommendation, not a requirement. But its not
clear that you actually want to avoid an exponential back-off. Its easy
to think of situations (such as the base station going 
down) where there would be a significant amount of retransmission
traffic from a large number of hosts.

[TELE]
We had an email exchange with Gorry and he agreed on the current text at
the end of section 6.3
(See Gorry's email from 6/8/2008)

[TELE]
Fixed.

[TELE]
I see in the Mishop agenda an item to discuss such issue in the WG. I
guess we can quickly update the ID accordingly afterwards.

I did not notice changes relating to the following:

> clients that send event/command services to. Is this a part of the 
> IEEE definitions, and you subscribe to a particular event stream? In 
> any case, the document should talk about this and point to the 
> relevant other specifications where needed.
>
[TELE]
Beginning of section 6 mentions the fact that capabilities discovery and
subscription procedures are specified in IEEE802.21

>> >    to.  [RFC3118 <http://tools.ietf.org/html/rfc3118>] provides
mechanisms for both entity authentication and
> relying on link layer security.

[TELE]
Text will be shown during the presentation.

Telemaco

Jari