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

["Thomas C. Schmidt" <schmidt at informatik.haw-hamburg.de>]

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: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °