Subject: [mobile-ip] Draft on mobile (MIPv6) PIM-SSM sources

From: "Christophe Jelger" <[email-masked]>
Date: Mon, 4 Feb 2002 14:52:00 +0100

Hi,

Two weeks ago we proposed a draft (draft-jelger-mssmsv6-00.txt) called
"Supporting Mobile SSM
Sources for IPv6 (MSSMSv6)" that proposes a solution to handle mobile
(MIPv6) PIM-SSM sources.

We hope that some of you have had the time to read it and we would be
pleased to hear your comments and suggestions. We would like to start a
discussion of the subject and gather people's comments and ideas in order to
be able to improve our current proposal.

We look forward to receiving your comments.

Christophe Jelger and Thomas Noel

---------------------------------------------------------------
Christophe Jelger - LSIIT           [email-masked]
Université Louis Pasteur
Strasbourg - France                   Tel: +33 (0)3 90 24 45 90

http://www-r2.u-strasbg.fr/~jelger
---------------------------------------------------------------

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 04 Feb 2002 16:18:33 +0200

Christophe,

> Sources for IPv6 (MSSMSv6)" that proposes a solution to handle mobile

...

> We look forward to receiving your comments.

Some possible security and other problems that I noticed:

  1. Your scheme depends on the assumption that there is
     a reverse tunnel to the old AR.  This may not be always
     the case.

  2. You can't just leave security with the note that you are
     not aware of any additional security problems than those related to
     MIPv6 and PIM-SSM.  Firstly, even combining two completely
     secure mechanisms is prone to introducing new security problems.
     Secondly, the MIPv6 security solution seems to be based on
     the idea of Return Routability (RR), possibly enhanced with
     optional Cryptographically Generated Addresses (CGA).
     At least to me it is not at all clear how to apply these
     techniques to multicast groups.  If you don't address this,
     your proposal is prone to a large class of different DoS
     and perhaps other attacks.

  3. You include a new feature, the nSA suboption to the Binding
     Updates.  I have the feeling that this may have nasty security
     problems unless properly authorized.  Unfortunately my
     understanding about the nature of the building up and management
     of multicast trees is too vague that I could properly analyze this.

--Pekka Nikander

---

From: "Rolland Vida" <[email-masked]>
Date: Tue, 5 Feb 2002 14:55:56 +0100

Hi,

Dave Thaler presented a similar solution to this problem in the Magma WG at
the last IETF meeting in SLC. See his slides at :
http://www.ietf.org/proceedings/01dec/slides/magma-2.pdf
The basic difference between the two approaches, as I see it, is that Dave
proposes to send the BUs on the original tree, rooted at the HA, while you
want to send them on the tree rooted at the old CoA.
The problem is how to treat a rapidly moving source. I explain:

1. Imagine that the source moves to foreign domain 1, and acquires CoA1.
2. It sends a BU to the HA, which forwards it on the original tree (HA,G).
Receivers will start to send their joins to CoA1.
3. BEFORE the tree gets totally reconstructed, the source moves again, in
domain 2, and acquires CoA2.
4. You say that the source should send then a BU to the CoA1, which will
forward the new address CoA2 down on the (CoA1,G) tree. But as the tree
reconstruction was not finished, there will be some receivers who will not
receive this BU. Should CoA2 send a BU to the HA too (as there are still
receivers on the old tree)? Or should CoA1 send this BU to the HA, on behalf
of CoA2? This would generate a possible security problem.

If, on the other hand, you apply Dave's solution, the fact that receivers
will stay on the original tree (HA,G) assures you that they will always
receive the BUs.

Rolland

> -----Message d'origine-----
> De : [email-masked]
> [mailto:[email-masked]]De la part de Christophe
> Jelger
> Envoyé : lundi 4 février 2002 14:52
> À : [email-masked]
> Objet : [mobile-ip] Draft on mobile (MIPv6) PIM-SSM sources
>
>
> Hi,
>

---

From: Christophe Jelger <[email-masked]>
Date: Tue, 05 Feb 2002 15:28:09 +0100

Hello and thanks very much for your very good comments.

First I want to insist on the fact that Dave's solution is quite 
different in the sense that after the source handoff, there is no 
multicast delivery until receivers join the new tree. Also, we do not 
keep a tree rooted at the HA, I hope that the draft is clear enough 
about that. In our solution, multicast datagrams are still received on 
the old tree while receivers join the new one. Second, in Dave's 
solution there is a need to keep two trees, and the one rooted at the HA 
is almost never used (unless to send BU), and this means that extra 
router states are created for very little use. Moreover, I haven't seen 
anything about session and channel identifiers in Dave's proposal.

Also, I want to stress the fact that even after the source handoff, only 
one branch per receiver is active, since when the new branch is active 
(packets received on the new tree) the old branch is prunned.

Answering your point about a fast moving source (CoA1, CoA2, CoA3) : the 
source moves from CoA1 to CoA2, it sends an encapsulated BU on the tree 
rooted at CoA1, receivers start to join towards CoA2. The source moves 
to CoA3 before all receivers have joined CoA2. It sends a BU on the tree 
rooted at CoA1, and another BU on the tree rooted at CoA2. Receivers 
start to join CoA3. Data is sent on the three trees, so that receivers 
joining CoA3 still receive data on old trees. When the source is being 
notified by NSNIP (not covered in the draft) that there are no receivers 
on old trees (CoA1 and/or CoA2), it stops sending BU and data on the 
appropriate old tree. Also note that even if data is sent on the three 
trees, only one branch is active per receiver and therefore data is not 
sent three times more than with just one tree.

Of course, the best point in Dave's solution is, as you say, that 
receivers will always get the BU but it is also the case in our 
proposal. Our solution is slightly more complicated but we believe that 
it is the price to minimise the disruption time after a source handoff.

Please feel free to send me more comments, they are greatly appreciated.

Christophe

---

From: "Rolland Vida" <[email-masked]>
Date: Wed, 6 Feb 2002 14:58:56 +0100

Cristophe,

> multicast delivery until receivers join the new tree.

At the IETF, Dave only presented the problem, and described a possible
solution. He did not enter in the details, he did not put it in a draft yet,
as far as I know. So the details can be discussed. The idea that you do not
prune off the branch of the old tree before receiving data on the new one,
is OK. But you can do the same thing with Dave's solution. The only
difference is the path on which you receive BUs.

> in Dave's solution there is a need to keep two trees, and the one rooted
at the HA
> router states are created for very little use.

That might be true. It might be inefficient, but maybe necessary.

> Moreover, I haven't seen

As I said, Dave presented only a proposal, not an entire draft, treating all
the possible details.
But talking about this issue, I have a related question.
How do you manage newcomer receivers? As far as I understood, you will
advertise the cCoA of the source, and everybody that wants to join the
session, should be aware of the current position of the source. This means
that all the time the source moves, it should update the information in the
whole Internet.
Otherwise, if a newomer tries to join a CoA, and the source already moved,
the join will be lost. On the other hand, if a newomer sends its joins
towards the home domain, it will always succeed. The problem is that in the
home domain there is a HA that tunnels packets. In a foreign domain there's
no such agent.

So how do you transmit this channel address change in the Internet? You
might use a multicast tree for this, and here we are with your second tree,
that you wanted to avoid in the first place.

> (packets received on the new tree) the old branch is prunned.

Yes, but for a sparse group and a rapidly moving source, you might lose
completely the advantages of multicast, and use only tunnels and branches
with a single receiver (i.e. unicast).

Rolland

---

From: Christophe Jelger <[email-masked]>
Date: Wed, 06 Feb 2002 15:30:26 +0100

Hi Rolland and thanks for your comments,

Newcomer receivers is indeed an interesting issue in our proposal. We 
proposed to use an extended version of SDR (which, once again, is not 
covered in the current draft) that should be capable of annoucing the 
CoA, the group address, and also the source home address H@.  A new 
receiver would be interested by the pair (H@,G) which we call the SSM 
session, and would connect to the tree (CoA,G) which we call the SSM 
channel. You are right when you say that this information should be made 
known to the whole Internet, but that's the way it works now with the 
current version of SDR. It is however important to note that the SDR 
tree is a shared tree, i.e. there is only one tree for the whole set of 
multicast groups/sources. Therefore we do not add an extra tree, it 
already exists and we just propose to extend this solution to announce 
the (CoA,G,H@) information needed to join the tree.

Of course, Dave's solution which is to keep a tree rooted at the home 
agent avoids the need for an extended version of SDR. But a new receiver 
still needs to be made aware of the (H@,G) pair, and unless you want to 
have it statically somewhere (e.g. on a web site), SDR should still be 
used and you'll also have to join the SDR shared tree.

Well we really appreciate your replies and we are very opened to people 
comments and suggestions. In fact, it would be interesting to see new 
ideas and  proposals (that are not in our current draft) which could be 
compared with our current solution (which is still a draft 00, and is 
far from being complete). Maybe this could lead to a common effort to 
propose a new unique draft combining the best parts of all solutions.

Best regards,

Christophe