Re: [Mobopts] IESG 3932 review of draft-irtf-mobopts-mmcastv6-ps

["Thomas C. Schmidt" <[e-mail]>]

Hi Jari,

many thanks again for your careful review - we are now back with 
addressing your points in detail (please see inline).
A new version of the document addresses the issues, and does not modify 
the recommendations.
The updated document is accessible at 
http://www.ietf.org/id/draft-irtf-mobopts-mmcastv6-ps-09.txt

Thomas

Jari Arkko wrote:

> 
>> obility management may issue
>>    traffic directives that lead to suboptimal routing, i.e., erroneous
>>    subscriptions following predictive handover operations, or slow
>>    effective leaves caused by MLD querying, or by departure of the MN
>>    from a previous network without leaving the subscribed groups.
>>   
> 
> I had a hard time parsing this. Maybe say instead: "Mobility management 
> may impact routing by, e.g., erroneous ... or by MNs leaving networks 
> without unsubscribing form the groups they were receiving.". What's a 
> "slow effective leave"?
> 

We replaced the first part as suggested.

2nd part changed to: "slow traffic termination at leaf nodes resulting 
from MLD query timeouts"
Hope this is clearer, now.

>> IP multicast deployment in general has been hesitant over the past 15
>>    years
> 
> s/hesitant/slow/?
> 
Changed.

>> a strong business case for IP
>>    portables
> ... portable IP-based devices.
> 
Changed.

>> Current packet filtering practice causes inter-working problems 
>> between Mobile IPv6 nodes connected via GPRS [46 
>> <http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-08#ref-46>].
>>   
> This is incorrect AFAIK. There are filtering procedures in IMS that 
> cause problems for Mobile IPv6 and other things. However, those 
> filtering mechanisms are not a part of the link layer nor are they 
> applied for regular Internet access. I would suggest this statement be 
> deleted from the draft, along with the reference.

D'accord: this isn't really important text. We removed as suggested.

> 
>> PTM uses an
>>    unidirectional common channel, operating in unacknowledged without
>>    adjustment of power levels and no reporting on lost packets.
>>   
> 
> ... unacknowledged mode?
> 

Yes, of course: thanks!

>>  Mobility services transport for MIH naturally reside
>>    on the network layer and are currently in the process of
>>    specification [55 
>> <http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-08#ref-55>].
>>
>>   
> draft-ietf-mipshop-mstp-solution is an approved specification (though 
> not yet out of the RFC Ed queue).
> 

O.K.: we changed to "have been specified" and refer to the draft ---
RFC-Ed can replace with this an RFC No when published.

> Also, I believe 802.21 specifies both network and link layer transport, 
> so its not clear why you say "naturally" above.
> 

Yes, but the point here was a bit different: Given link layer 
heterogeneity (beyond IEEE protocols) and the need to transfer states of 
multicast context, an abstraction above layer 2 is needed.

We changed the sentence to
"Mobility services transport for MIH are required as an abstraction for 
layer 2 multicast service transfer in an Internet context [54] and are 
specified in [55]."

> In general Section 4 wanders off a little bit to topics outside 
> multicast. I understand that some amount of explanation is needed about 
> what each L2 technology does, but I'd consider tightening the text in 
> AUTH48 in some places.
>

We agree that wireless link layer issues and mobile multicast routing 
are distinct topics and should be designed independently. However, 
mapping group communication well to distribution techniques on a shared 
link (s.a. in wireless) is  an important challenge (the efficiency of 
group communication increases with lowering the layers). And - as Rajeev 
& Charlie nicely state in their book - "It's hard to imagine being 
mobile without assuming wireless" ;)

So we tried to summarize the clues of l2 multicast capabilities - even 
if being a bit verbose. Following your hint, we tightened the text at 
many occasions, which is difficult to enumerate but easy to see from the 
diff.

>> MLD
>>    router querying will allow the multicast forwarding state to be
>>    restored in case of an erroneous prediction (i.e., an anticipated
>>    move to a network that is not fulfilled).
> fulfilled?
> 

Reworded: "has not taken place".

>>    Mobility protocols need to consider the implications and requirements
>>    for AAA. AAA binding records may change between attachments, or may
>>    be individually chosen prior to network (re-)association. The most
>>    appropriate network path may be one that satisfies user preferences,
>>    e.g., to use/avoid a specific network, minimize monetary cost, etc,
>>    rather than one that only minimizes the routing cost. Consequently,
>>    AAA bindings cannot be treated at a pure level of context transfer.
>>   
> It was not clear to me why AAA is relevant. And what's an "AAA binding 
> record"? I must say that I don't understand the rest of the paragraph 
> either.
> 
> The term AAA was not defined or expanded. Please check the other terms too.
> 

The issue pointed at here is that multicast (as a special per group 
service) may not be part of the standard connectivity offer of an 
operator (example: IPTV - realized as a multicast service - is offered 
as an additional, charged service by a number of European providers 
today). Re-routing may involve provider changes and thus be incompatible 
with "seamless/unnoticed network management operations".
This paragraph is an outcome of a discussion with Dave Thaler and Bill 
Atwood.

We reworded as follows:

"Mobility protocols need to consider the implications and requirements 
for Authentication, Authorization and Accounting (AAA). A MN may have 
been authorized to receive a specific multicast group when using one 
mobile network, but this may not be valid when attaching to a different 
network. In general, the AAA association for an MN may change between 
attachments, or may be individually chosen prior to network 
(re-)association. The most appropriate network path may be one that 
satisfies user preferences, e.g., to use/avoid a specific network, 
minimize monetary cost, etc, rather than one that only minimizes the 
routing cost. Consequently, AAA bindings may need to be considered when 
performing context transfer."

Better now?

>> Due to lack of feedback, the admission [83 
>> <http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-08#ref-83>] 
>> and binding
>>    updates [84 
>> <http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-08#ref-84>] 
>> of mobile multicast sources require autonomously
>>    verifiable authentication as can be achieved by Cryptographically
>>    Generated Addresses (CGAs).
>>   
> And presumably with other means as well. I would suggest saying "... be 
> achieved by, for instance, ...".

O.K. - changed.

> 
> It would have been interesting if Section 8 listed some of the multicast 
> specific issues around security. For instance, I would presume that a HA 
> operating tunneled multicast service by n-casting is more vulnerable to 
> a DoS attack than some other more native multicast solution.
> 

Multicast security concerns and counter measures is indeed a large issue 
- we don't know of any sufficiently general reference. Instead, we have 
added the following paragraph:

"Multicast protocols exhibit a risk of network-based traffic 
amplification. For example, an attacker may abuse mobility signaling to 
inject unwanted traffic into a previously established multicast 
distribution infrastructure. These threats are partially mitigated by 
reverse path forwarding checks by multicast routers. However, a 
multicast or mobility agent that explicitly replicates multicast 
streams, e.g., Home Agent that n-casts data, may be vulnerable to denial 
of service attacks. In addition to source authentication, a rate control 
of the replicator may be required to protect the agent and the 
downstream network."

We know there could be a larger story on multicast security, which 
interferes with mobility. However, given the focus of this document to 
address only a brief survey of the design space, we think it should 
suffice to only sketch the security concerns and leave details to actual 
protocol design.

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: [phone] °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °