Re :Re: [Mobopts] Re: [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt

[Kyungjoo Suh <[e-mail]>]

HI, Rod, Thoma, and James, 

First of all, thank you so much for reviewing the draft. 
Here I quickly answer for some questions. 
welcome any comments. 

 How does the PAR learn of the NAR address ?

answer : We assume that the proposed scheme is operating on top of FMIPv6.
In the FMIPv6 spec. it is assumed that PAR knows the NAR's address. Actually, this problem is not mentioned
in the FMIPv6 spec. but left as unsolved problem. The problem is addressed in Seamoby WG. It is related to
the CARD (Candidate Access Router Discovery) protocol and the reverse address translation (RAT). Precise information
can be obtained from the current draft of the CARD protocol. In this version of draft, we do not address this
problem because we are not proposing an enhancement version of FMIPv6 but a mutlicast protocol operating with FMIPv6.
Therefore we assumed the same network situations (environments) as it assumed in the FMIPv6 draft.
Except this assumption, to know the NAR address in advance, roughly there are two methods that can be applied to the
proposed protocol. First, we may explicitly preconfigure or set the address of neighboring AR (this address is the address
assigned to the wireless interface of the AR) to each AR.
Second, a neighbor AR learning algorithm (NALA) can be used. To learn the neighbor AR's address, MN may send
the previous AR's address to its current AR after performing handoff. Using this method, AR can learn the addresses of 
neighboring ARs. For more precise information on the second method, please refer to the ARIP draft (draft-....).

Some discussion on IGMP/MLD-snooping and the role of access points as switches could be appropriate too-
to deal with the situation where AP changes but AR does not.

answer : In this version of draft, we only assume that the AR has the functionality of a AP to simplify our ideas.
In the next version, we will also consider the situations what you mentioned.
(draft-ietf-magma-snoop-10.txt : Considerations for IGMP and MLD Snooping Switches)
(draft-ietf-magma-igmp-proxy-04.txt : IGMP/MLD-based Multicast Forwarding ("IGMP/MLD Proxying"))

Security Risks.

answer : You're right. We just explain the protocol operation in this version. And we are going to include the solution 
for security risk in next version. As you mentioned, existing solutions such as MCOP, IGAP, and MAGMA to achieve SSM 
can be applied to our proposal.
But, as I mentioned the operation of the proposed protocol is operating on top of FMIPv6. If FMIPv6 is secure enough, there
may be no problems at all what you mentioned. This is because by the secure operations (signalings) of FMIPv6 itself (we think
the secure operation of FMIPv6 is not fully addressed in the WG yet). such as secured (AAA passed) Router Solicitation for Proxy, 
Proxy Router Advertisement, HI, HACK, FBU and etc. The situation (DoS possibilities) happens when the malicious HI message is 
received at NAR not knowing that the message is generated by some attackers. But, the malicious HI messages cannot be generated 
if only authorized MNs are allowed to perform the FMIPv6 procedure. Even with this assumption (Secure FMIPv6), we admit that 
there are a lot of security holes that we didn't think of. 


Tunnelling

answer : As mentioned earlier, our proposal is based on the FMIPv6 protocol. In the FMIPv6 protocol, there is
a tunnelling scheme between PAR and the NCoA to forwarding data destined to the MN during MN's handoff. The FMIPv6
protocol only explains how create this tunnel. There is no explicit scheme for tunnel destruction. But, I think that
the tunnels in the FMIPv6 spec. are soft-state based tunnels as they are in MIPv6. In other words, those tunnels are 
destroyed after some predefined threshold time for existence.
Also we may consider an explicit tunnel destroy mechanism using MLD Done message. In our proposal, MN sends the MLD Done
message to the PAR when it start receiving multicast packets directly from NAR. Therefore, PAR can destroy the
tunnel when it receives the MLD Done message.
However, thanks about your pointing outs.


Scope of draft

You're right. Our current draft concentrating on solving the multicast receiver problem when it handoffs. 
We also considered the case when MN becomes a sender. Two distinct mechanisms that we are currently thinking exist for 
a multicast sender problem.
The first solution is a quite primitive one and it is to make MN to use the home-agent based multicast scheme when 
it is a multicast sender.
In the second solution, MN may use the temporal "reverse" tunnel from PAR to MN until NAR finishes the join process to
the multicast tree. We have a plan to include the multicast sender situation in the next version.


Reference

answer : We know that draft-ietf-mobileip-ipv6-24.txt is last version and will be RFC soon.

Again, thank you  for your  comments.

best regards,
Joo (Kyungjoo Suh) 

------- Original Message ---------------------------------------------------------------------------------------------------------------------------------------------------------
Sender : James Kempf<[e-mail]> 
Date   : 2004-03-04 09:30
Title  : Re: [Mobopts] Re: [Mip6] NEW ID
 ACTION:draft-suh-mipshop-fmcast-mip6-00.txt

> > I quickly read your Internet draft with interest and would like to
> > know if you will intend to discuss it on the mobopts mail list?
> >
> > I have been working on multicast to mobiles for some time and would
> > be happy to exchange ideas.
> >
Actually, we've found it the case of FMIPv4 on 802.11 that the performance
for reactive handover is perfectly adequate. There is some slight additional
delay and one loses packets during the L2 handover (if the proprietary
buffer fowarding at the AP is turned off) but other than that, it works
fine. Unfortuantely, I can't send the paper out because it is under
consideration for publication. We haven't specifically looked at multicast,
but I can't see how it could be a problem. The multicast traffic will get
forwarded through the tunnel until the mobile node does MLD for the group
with the new router, at which point the routing change will propagate. There
is of course an issue with the route propagating, and, in that sense, HMIP
might be better if the multicast routing tree is rooted in the MAP.

            jak


> >
> > Here are some early thoughts on your document:
> >
> > The problem and solution seem to do a good job for multicast
> > receivers.
> >
> A matter of debate could be, wether FMIPv6 is a well suited fundament
> for multicast distribution. FMIP must be eager to anticipate handovers
> (if it will work well), thus exhibiting a significant likelyhood of
> wrong predictions.
>
> In the multicast case this will lead to an unwanted quantity of uneeded
> remote subscriptions, unneccessary branches in the multicast trees ...
>
> ... from our point of view the smoother hmipv6 MAP architecture is much
> more appropriate as multicast agents ...
>
> > How does the PAR learn of the NAR address? (In the sense that: Is
> > there something that would be in scope for Multicast Fast Handover,
> > that's different from unicast/existing fast handover?)
> >
>
> If we understand correctly: This is just taken from FMIPv6's prediction.
>   There should be nothing exclusive to multicast.
>
> > Some discussion on IGMP/MLD-snooping and the role of access points as
> > switches could be appropriate too - to deal with the situation where
> > AP changes but AR does not.
>
> Mhmm, this might be more a concern of underlying L2 specification. The
> FMIPv6 approach leaves L2 specs to additional documents.
> >
> > Also, there are several security risks. Of particular trouble are the
> > DoS possibilities of setting up state in many "NARs" by a
> > broken/malicious "MN", and sending to multiple ARs malicious
> > multicast data (e.g. to destroy usability of the "expected service").
> > SSM is worth mentioning and also access control. As far as I am
> > certain there are 2 ongoing activities on multicast (AR) access
> > control: MCOP, IGAP. And I think there's a 3rd in MAGMA - so no need
> > to address the whole access control solution, just explain the impact
> > and use for this fast multicast handover. (I guess you already have
> > these ideas for the 01 draft :)
> >
> > Tunnelling multicast from PAR to NAR is not so scalable, this should
> > be mentioned. Perhaps suggest a means to time-out these tunnels so
> > that the tunnelling is only transitory since using the "PAR" as the
> > tunnel other-end point reduces scalability of that AR.
> >
> Tunneling in this approach only occurs, if NAR refuses to subscribe to
> the wanted multicast group ... question is: when will this happen? On
> which bases would a NAR decide not to support a specific group?
>
> Cheers,
>
> Thomas & Matthias
>
>
> <more of the previous mails to come for mobopts folks:>
>
> > The differentiation between receiver-only, sender-only and
> > reciever+sender MNs would be a good discussion item too. For
> > instance, I think your solution is great for receivers, but for
> > senders (especially send-only non-group-members) it does not solve
> > the problem. Perhaps this is just an issue of limiting the scope to
> > receiver mobility. Maybe it is currently helping readability to not
> > cover sender mobility in this draft, so one option is to consider
> > these aspects in a separate draft - at the same time or a later
> > stage.
> >
> > Also, one small NIT: please make it explicit which references are
> > normative (essential) and which are informative (I guess all 4 are
> > normative)?
> >
> > Have you had any earlier feedback or discussion on the MIPSHOP (or
> > other WG) email lists?
> >
> >
> > Cheers, Rod.
> >
> >
> >
> > -----Original Message----- From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of ext Kyungjoo Suh Sent:
> > Wednesday, March 03, 2004 3:05 PM To: [e-mail] ; ??? Subject:
> > [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt
> >
> >
> > Hi,
> >
> > New draft is available which is Fast multicast protocol.
> >
> > This document defines the Fast Multicast Protocol for Mobile IPv6 [2]
> > in the Fast Handovers environments whereby a mobile node (MN) can
> > receive multicast data with reduced loss and delay after handoffs.
> >
> > Please refer to following document.
> >
> > sincerely, Kyungjoo Suh (Joo)
> >
> >
> >
> >
============================================================================
=======================
> >
> >
> > I-D ACTION:draft-suh-mipshop-fmcast-mip6-00.txt
> >
>
> --------------------------------------------------------------------------
------
> >
> >
> > To: IETF-Announce: ; Subject: I-D
> > ACTION:draft-suh-mipshop-fmcast-mip6-00.txt From: Internet-Drafts at
> > ietf.org Date: Fri, 06 Feb 2004 15:41:59 -0500 Reply-to:
> > Internet-Drafts at ietf.org Sender: owner-ietf-announce at ietf.org
> >
>
> --------------------------------------------------------------------------
------
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> > Title : Fast Multicast Protocol for Mobile IPv6 Author(s) : K. Suh
> > Filename : draft-suh-mipshop-fmcast-mip6-00.txt Pages : 13 Date :
> > 2004-2-6  This document defines the Fast Multicast Protocol for
> > Mobile IPv6 [2] in the Fast Handovers environments whereby a mobile
> > node (MN) can receive multicast data with reduced loss and delay
> > after handoffs. The proposed protocol can be implemented by the
> > simple modification of the Fast Handovers protocol [1] so that it can
> > be easily applied to the Fast Handovers for Mobile IPv6. This
> > document does not need a certain assumption of a specific multicast
> > routing protocol, so that any existing multicast routing protocol can
> > be used with the proposed protocol.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-suh-mipshop-fmcast-mip6-00.txt
> >
> >
> > To remove yourself from the IETF Announcement list, send a message to
> >  ietf-announce-request with the word unsubscribe in the body of the
> > message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> > username "anonymous" and a password of your e-mail address. After
> > logging in, type "cd internet-drafts" and then "get
> > draft-suh-mipshop-fmcast-mip6-00.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to: [e-mail]. In the body type: "FILE
> > /internet-drafts/draft-suh-mipshop-fmcast-mip6-00.txt".  NOTE: The
> > mail server at ietf.org can return the document in MIME-encoded form
> > by using the "mpack" utility.  To use this feature, insert the
> > command "ENCODING mime" before the "FILE" command.  To decode the
> > response(s), you will need "munpack" or a MIME-compliant mail reader.
> > Different MIME-compliant mail readers exhibit different behavior,
> > especially when dealing with "multipart" MIME messages (i.e.
> > documents which have been split up into multiple messages), so check
> > your local documentation on how to manipulate these messages.   Below
> > is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> >
<ftp://ftp.ietf.org/internet-drafts/draft-suh-mipshop-fmcast-mip6-00.txt>
> >
> >
> >
> > _______________________________________________ Mip6 mailing list
> > [e-mail] https://www.ietf.org/mailman/listinfo/mip6
> >
> > _______________________________________________ Mip6 mailing list
> > [e-mail] https://www.ietf.org/mailman/listinfo/mip6
> >
>
> _______________________________________________
> Mobopts mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mobopts
>


_______________________________________________
Mip6 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mip6




_______________________________________________
Mip6 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mip6