Subject: [mobile-ip] Re: I-D ACTION:draft-jelger-mssmsv6-00.txt

From: Pekka Savola <[email-masked]>
Date: Fri, 8 Feb 2002 17:48:42 +0200 (EET)

On Wed, 23 Jan 2002 [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: Supporting Mobile SSM Sources for IPv6 (MSSMSv6)
> 	Author(s)	: C. Jelger, T. Noel
> 	Filename	: draft-jelger-mssmsv6-00.txt
> 	Pages		: 11
> 	Date		: 22-Jan-02

A few comments I made on a flight.

2.1.1 Advantages and drawbacks 

   [...]. A failure of the HA would cause multiple multicast delivery    
   disruptions. 

==> Failure of the HA would, AFAICS, cause disruptions for MIP traffic 
too: so nothing new there. 

               Third, the processing task of the HA increases with the
   number of mobile sources it serves, thus reducing the efficiency of
   the multicast delivery and increasing the probability of a failure. 

==> How many Mobile multicast-sourcing nodes would you expect a random HA 
will have to serve?

==> In general, this mechanism makes delivery more unstable: moving 
sources send BU's to recipients.  Recipients must authenticate those BU's 
(e.g. with return routability (with multicast??)).  You force the burden 
on multiple recipients, when the same could be done at one place, mobile 
source.

==> Also, in multicast I don't think it's that usual that sending latency 
is that big a problem: communication is mostly one-way.

2.2.1 Source handover 
  When a mobile SSM source moves into a new subnet, it must inform the
   multicast receivers about its new Care_of-Address (nCoA).

==> inform how?

==> what about recipients not implementing BU processing or not having it 
enabled?

               the BU message must be encapsulated towards the old   
   Access Router (oAR)

==> how is oAR known?  Note that remembering link-local address from route 
advertisements is not enough (:-)

 This   
   notification could be done via the Multicast Source Notification of 
   Interest Protocol (MSNIP) but it is out of the scope of this
   document.

==> Add a reference to MSNIP draft.

==> I'm a bit curious why exactly this is "out of scope"...

==> Around this place in the draft there seems to be significant 
duplication of tex with section 2.2.3.

   SHOULD forward the multicast datagrams sent by the MN from the new 
   subnet onto its local interfaces (e.g. interfaces binded with the   

==> s/binded/bound/

3. Implementation requirements

==> You forget new requirements for oAR's

4. Security Considerations
 
   The proposed protocol MSSMSv6 does not introduce new security
   problems that those already present in MIPv6 and PIM-SSM.

==> A daring thing to say.

==> How is the tunnel between oAR and MN established?  Does oAR have to 
blindly decapsulate the packets from everywhere?  This is a huge risk.  
Remember that oAR doesn't need to know _anything_ about nodes visiting its 
subnet (it's not IPv4 Foreign Agent)...

==> About BU with optional SSM destination option.  Could MN cause 
recipient that marginally trusts it join new SSM sessions (nothing related 
to what MN is originating, for example) and possibly subsequently have it 
kill old ones?

==> BU with multicast destination will need a _lot_ more thorough analysis 
I think.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: "Christophe Jelger" <[email-masked]>
Date: Mon, 11 Feb 2002 13:55:02 +0100

Hi Pekka and thanks very much for your comments,

I will try to answer your comments, indicating the paragraph number.

2.1.1

- Indeed, failure of the HA would cause disruption with MIP but is this
comment very relevant to our draft? (I mean, this is not something we have
tried to solve).
- It's true that one single HA will not have to serve many mobile sources
(statistically), but that does not mean that a solution should not be
optimised if this rare event occurs (a HA with many mobile sources to
serve).
- BU authentication is obviously an important matter. I unfortunatly cannot
follow the day-to-day talks about this subject on the mobile ip mailing
list, but if the mobile ip wg finds a suitable way to do it for traditional
unicast communications, the same solution could also be used in our proposed
protocol. However, we currently study different mechanisms that could be
used to authenticate the BU in our proposal (not for use in the traditional
mobile ip operation).

2.2.1

- Method used to inform receivers about nCoA : this is the whole purpose of
our draft.
- Obviously receivers must have adequate functionality to process the new BU
type (as explained in a latter section of the draft).
- The global address (i.e. not the link-local address) of oAR is known as it
is the previous AR of the MN (known in MIP)
- Adding a reference to MSNIP draft : good comment, I will make sure it will
be in the next version of the draft.
- About MSNIP being out of the scope of the current draft : we still need
time to investigate the proposed method, especially the use of encapsulated
messages with MSNIP.

3. I will bare in mind your comment, but as far as I know, oAR does not need
modifications (if we don't consider the authentication mechanism).

4. Actually there is no real tunnel establishment between oAR and MN, we
just use IP-IP encapsulation. Obviously, this matter needs further
investigation to check the behaviour of oAR

I am afraid but I do not fully understand your last point about "killing"
old sessions. Could you please re-formulate ?

And last, you are right when saying that multicast BU needs further in depth
investigation. This is something we are currently doing.

Thanks again for your comments which are greatly appreciated. There are
still many things we need to check and validate before submitting a second
version of the draft and we are very opened to suggestions and critical
comments from other researchers. Therefore, comments are welcome as they
allow us to see problems that we haven't thought about.

Best regards,

Christophe

----- Original Message -----
From: "Pekka Savola" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Friday, February 08, 2002 4:48 PM
Subject: [mobile-ip] Re: I-D ACTION:draft-jelger-mssmsv6-00.txt