Re: [Mip4] Summary of security issues (was RE: WGLC:draft-ietf-mip4-generic-notification-message-04.txt)

Hi folks.  I think this draft needs more review.  Some comments on
version 06.

1) Sect. 3.2.

It's confusing to show "notificaton" from AAA to FA.  Maybe the arrow
can be named "trigger" since the notification message is from FA to MN
and to HA?

2) Sect. 3 usage scenarios clarificaton.  Can MN send notification to
FA?  MN to HA via FA or direct?

3) Sect. 4.1. Reference RFC 3115 for VSE and RFC 4917 for generic
string.  Not clear how binding revocation is applied in GNM?

   A generic notification message is sent by a mobility agent to inform
   another mobility agent, or a mobile node, of MIP-related information
   such as vendor specific extensions, generic string notification or
   binding revocation.

3b) Sect. 4.1. The IP destination address should be "Same as the last
Registration Reply/Request message received".  Also, shouldn't the
source IP address and port be same as the last registration message?
This would support NAT traversal and ensure same security association
used for GNM/GNA and RRQ/RRP.

   ... These messages must use the same IP and UDP
   headers as any previous Registration Request or Reply message to the
   same entity.  The generic notification message is defined as follows:

   IP Fields:

     Source Address         Sender's address.

     Destination Address    Receiver's address.

   UDP Fields:

     Source Port            variable.

     Destination Port       Same as the last Registration Reply/Request
                            message.

4) Sect. 4.1. What is the Binding Revocation extension?  RFC 3543
specifies Revocation Support Extension to indicate MN or FA supports
revocation function.  But this extension does not provide notification
or revocation. 

      3 Information carried in Binding Revocation extension

5) Typo "foreing" -> "foreign":

      5 -- Message sent by the foreing agent to the home agent

6) Using nonce method requires much more operational description (e.g.
HA does not have nonce value with MN after registration).  Replay
protection using timestamp should be covered in a section for clarity.
For example, FA -> MN GNM security is not covered by RFC 3344.

   Identification

      A 64-bit number, constructed by the sender, used for matching
      Generic Notification with Generic Notification Acknowledgement,
      and for protecting against replay attacks of notification
      messages.  Here is the same as Sections 5.4 and 5.7 of [RFC3344].
      Timestamps is mandatory and nonces is optional.

7) Sect. 4.2. Why is the GNA's source UDP port not copied from the GNM?
NAT traversal issue (when NAT between FA and HA) if not copied.

   UDP Fields:

     Source Port            variable.

8) Sect. 4.2.  Why values 2 and 3 are not described?  As noted before,
I'm not clear about value 3.

      The value 0 is reserved and should not be used.  The value 1
      indicates that the actual information is carried in vendor
      specific extensions.  Other values are reserved for future
      extensions.

9) Sect. 4.2. Is MD needed in GNA?  GNA is in response to GNM so MD
should be known.  Also, not sure if HA and CoA address fields needed in
GNA?

10) Sect. 4.2. The description does not cover Identification field.  

   Identification

      The fixed portion of the Generic Notification Message is followed
      by one or more extensions which may be used with this message, and
      by one or more authentication extensions (as defined in Section
      3.5 of [RFC3344].

11) Sect. 4.2. There are 3 defined cases: VSE, generic string, and
revocation extension.  VSE is handled by each vendor.  I assume that
generic string handling is based on RFC 4917.  Revocation is unclear.

If the mobile node accepts the home agent's generic
   notification message, it will process it according to the specific
   rules for that extension. 

12) Sect. 4.3.2. source address should be MN's HoA in the case of
FA-CoA.  Destination address should be FA.

   In the case of a FA-CoA, the source address is the mobile node's CoA
   address and the destination address is the home agent's address ("MD"
   value is set to 2),

13) Sect. 4.4.1. FHAE is optional for GNM from HA to MN via FA, right?

   If the "MD" value is set to 0, the foreign agent MUST check the FA-HA
   AE and Authenticator value in the Extension if the Foreign-Home
   Authentication extension is presented. if more than one Foreign-Home
   Authentication Extension is found, or if the Authenticator is
   invalid, the foreign agent MUST silently discard the Notification
   message. 

14) Sect 4.4.3.  How does FA know the timestamp of the HA to send GNM?
Does FA have to glean the Identification field in the RRP?  Need
clarification here.  Also, if FA maintains some timestamp value for each
HA, and vice versa, that needs to be added to FA and HA considerations.

15) 4.5. Since RFC 4917 was intended for MN to receive a message from
the network, it's unclear what HA or FA will do when generic string is
received?

16) 4.5.  Shouldn't HA acknowledge the receipt of the GNM in this case?

If the home agent receives a notification message
   from a foreign agent and there is no corresponding mobile node
   registration, the home agent should drop the notification message.

17) 4.5.2.  Should specify that HA sends GNM with A bit set when GNA is
not received.  Or this can be generically covered.

18) sects. 5 and 5.1.  The example for revoking the CDMA session can be
handled by revocation message (RFC 3543).  This adds to the confusion
when revocation message vs. GMN should be used.  May be good to clarify
that point.

19) 5.1. Typo "notificaiton".  There are other typos that can be checked
later.

20) 5.2. Not clear how this is different from revocation message with
generic message string extension?

21) Agree with Pete on the timestamp sync issue.  That means some use of
code 133 in GNA.  Should there be some Code field in GNA to confirm
positive or negative operation after receiving GNM?

22) NAI extension should be covered in draft.  Home Address is not
typically sufficient to identify the MN.

Kent
--
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/