Subject: Re: [NSIS] Request comments for Mobility draft

From: Hong Cheng <[email-masked]>
Date: Fri, 06 Jul 2007 09:09:39 +0800

Dear all,

Please find some comments regarding the security considerations of the
draft.

cheers

Cheng Hong

> =====
> 7.  Security Considerations
>
>    <snip>
>
>    The movement of the mobile node after the initial flow setup requires
>    authorization.  Various session ownership authorization issues are
>    illustrated in [10].
>
>
>
>         MN                    DCRN                      CN
>
>                                                            + E.g.
>         ------>----->------>------>------>------>------>   | Movement
>                             ACTION                         | with state
>                                                            | creation at
>         <-----<-----<------<------<------<------<-------   + new path
>                              ACK
>
>
>
>
>
> Sanda (Ed.), et al.     Expires September 6, 2007              [Page 34]
> 
> Internet-Draft         NSIS Signaling in Mobility             March 2007
>
>
>                        Figure 11: MN authorizes DCRN
>
>    The following questions are of interest:
>
>       - Why should the DCRN execute something on behalf of the MN?
>       (i.e., why should it trust the MN and what information can the
>       DCRN use for verification? [the trust is not the other way round:
>       the MN trusts the DCRN?])  As an example, the DCRN might delete
>       state along the old segment.

[Cheng] The MN is the Authorizing entity, why the DCRN cannot trust the
MN? This seems like a redundant questions. Suggest to remove it. Or, is
it trying to say something else?
[/Cheng]

>       - Should the DCRN alone be able to start signaling (the DCRN might
>       be a dedicated node in some mobility protocols (e.g., MAP)) since
>       it is the node which has more information than other nodes based
>       on the mobility signaling protocols?
>
>       - How should other nodes between the MN and the DCRN and the nodes
>       between the DCRN and the CN know that the DCRN is now acting on
>       behalf of the MN?
>
>    The case of a corresponding node triggering an action is discussed in
>    the paragraph below.  Figure 12 shows the exchange graphically.
>
>    In this scenario the CN wants to, for example, tear-down a
>    reservation.
>
>
>
>           MN                    DCRN                       CN
>
>          <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    +
>                             TRIGGER                          | E.g.
>                                                              | Tear
>                                                              | Down
>           ------>----->------>------>------>------>------>   |
>                               ACTION                         |
>                                                              |
>           <-----<-----<------<------<------<------<-------   +
>                                ACK
>
>
>                        Figure 12: CN triggers action
>
>    The following questions arise:
>
>       - Why should the MN trust the trigger?  Why should the
>       intermediate nodes trust it?
>   

[Cheng] Second part of the question looks suspicious. Is this TRIGGER a
direct message to MN? Why intermediate node need to process it since the
ACTION will anyway come from MN later? Suggest drop the second part.
[/Cheng]

>
>
>
> Sanda (Ed.), et al.     Expires September 6, 2007              [Page 35]
> 
> Internet-Draft         NSIS Signaling in Mobility             March 2007
>
>
>       - Is it possible to specify the security properties of the trigger
>       message in more detail?  Is this an NSIS signaling message?
>   

[Cheng] Related to the above question, another question to be asked is
probably "is this TRIGGER processed by intermediate node?"
[/Cheng]

>
>
>       - The discussions about an indicator which entity to charge for
>       the reservation might be relevant (see [12]).
>
>       - Should the CN restrict the actions of the MN (e.g., delete,
>       update, create action of established state information)?  On the
>       shared segment it might, for example, be possible to restrict the
>       allowed action to a flow identifier update.
>   

[Cheng] What does this mean? Isn't MN the authorizing entity? It can
carry out any action it sees suitable. CN is just providing the trigger
(or enough information) for MN to make a decision. In the above figure,
ACTION is sent from MN. Suggest to clarify the meaning of the above text.
[/Cheng]

> <snip>
>
>
>
> Sanda (Ed.), et al.     Expires September 6, 2007              [Page 37]
> 
> Internet-Draft         NSIS Signaling in Mobility             March 2007
>
>
>    delete).  An optimistic delete operation is certainly more error
>    prone.
>
>
>
>          MN                    DCNR                          CN
>
>       [    ~~~~~~~~~~~~ TRIGGER (e.g., MIP) ~~~~~~~~~~~~~~> ] +
>
>            ------<-----<------<------<------<------<------<   |
>                       ACTION  (CN is authz)                   |
>            +--------------------+  +-----------------+        |
>            |  Action:optimistic |  |  Action:        |        |
>            |  'delete' along    |  |  'update' along)|        |
>            |  old segment)      |  |  shared segment)|        |
>            +--------------------+  +-----------------+        |
>           >------>------>----------->------>------>-------    |
>            +-----------------+            ACK                 |
>            |  Action:        |                                | Action
>            |  'create' along)|                                |
>            |  new segment)   |                                |
>            +-----------------+                                |
>            <------<------<-------                             |
>            +-------------------+                              |
>            | Action:pessimistic|                              |
>            | 'delete' along)   |                              |
>            | old segment)      |                              |
>            +-------------------+                              |
>           =================Traffic==========================> +
>
>
>
>        Figure 14: CN uses installed state to route message backwards
>
>    Figure 14 raises a few questions:
>
>       The security properties of the trigger message need to be
>       evaluated.
>
>       It is not always possible to route signaling message backwards
>       from the CN to the MN:
>
>          - state at the new path might not be established (hence the
>          signaling message cannot travel backwards)
>   
[Cheng]: As the section title suggested: "CN uses install state to route
message backwards", why it has to do with whether the new path is
established or not?The above "ACTION" is to be routed along the old path.

The issue seems more likely associated with the message from "DCNR"
(?shouldn't this be DCRN?) towards MN.

Suggest to clarify this point or remove it.

[/Cheng]
>
>          - the signaling message might not reach the MN via the old
>          segment.
>
>
>
>
> Sanda (Ed.), et al.     Expires September 6, 2007              [Page 38]
> <snip>
>
> 7.2.  CN as data sender
>
>    In this section we consider the scenarios where the CN acts as a data
>    sender.  Figure 15 shows the topology and the participating entities.
>
> 7.2.1.  CN is authorizing entity
>
>    This scenario is similar to the one described in Section 6.1.1.  No
[Cheng]                                                                                                     
^^^^^^^^^^^^^^
    Is this the correct section number?
[/Cheng]

>
>
>    additional problems arise with a scenario where the CN is both data
>    sender and also the authorizing entity.  In Figure 15 the CN
>    authorizes the UCNR to delete the old segment and to establish a new
[Cheng]                           ^^^^^
change UCNR to UCRN
[/Cheng]

>
>    reservation along the new segment.  Furthermore, at the shared
>    segment only an update of the flow identifier might be necessary.
>
>
> Sanda (Ed.), et al.     Expires September 6, 2007              [Page 39]
> <snip>
> Internet-Draft         NSIS Signaling in Mobility             March 2007
>
>
> 7.2.2.  MN is authorizing entity
>
>    In this scenario we consider the case where the CN is the data sender
>    but the MN authorizes actions.  The considerations are similar to
>    those elaborated in Section 6.1.3 where the MN is the data sender but
[Cheng]                                      ^^^^^^^^^^^^^^
IS this the correct section number?
[/Cheng]
>
>
>
>    the CN is the authorizing entity.
>
> <snip>
>
> 7.3.2.  CN as data sender
>
>    This section shows the multi-homing scenario with the CN as a data
>    sender.  The scenario is simpler (for the CN authorizing case) than
>    the one described in Section 6.1 since the signaling message along
>    the shared segment travels the previously established path.  It shows
>    some similarities with a route change scenario.  At the mobile node
>    itself the two paths merge which again leads to a session ownership
>    problem.  How should the MN know whether a signaling message with the
>    same session identifier hitting a different interface belongs to the
>    indicated session authorized by the CN?

[Cheng] The issue above for MN is the same for the DCRN in the issue of
7.3.1. That is to say, it is a common problem for the DCRN for both cases.
[/Cheng]
Takako Sanda wrote:
> Hi all,
>
> Mobility Draft still have open issues and some sections need to clean up,
> such as.
> - NAT/FW interaction (open issue)
>   When MN moves, IP address and routing are changed. In this case, new
> NAT/FW pinhole need to be opened and old one should be torn. When and
> how should NSIS tear old pinhole?
> - Security consideration (need to clean up)
> - Terminology (need to clean up)
>
> For terminology section, authors plan to remove the terms which are not
> used in the main body (such as NSPL/NTLP/NSIS CRN). However other parts
> are not discussed well.
>
> Your comments will be highly appreciated ;-)
>
> cheers,
> Takako
>
>
>
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>
>
>   

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis