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

Hello, all

I plan to update the draft based on comments. let me try to repley each of
unresolved comments based on Sri's last time presentation slides. thanks for
all your reviews.

2008/7/28 Kent Leung (kleung) <kleung@cisco.com>

>
> 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?
>
[Hui] Revised, thanks

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

[Hui] Basically, I feel MN could send notification according to security SA.
but current document doesn't make any example, so let it be.

>
>
> 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.
>
[Hui] I plan to remove revocation support in this message, does any other
people
has different idea about it?

>
> 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.
>
[Hui] I can't remeber previous discussion, but it seems your suggestion is
reasonable, updated

   IP Fields:

     Source Address         Same as the last Registration Reply/Request
                            message received.

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

   UDP Fields:

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

     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
>
[Hui] You are correct, here is mistake, I plan to remove revocation support
from this document.

>
> 5) Typo "foreing" -> "foreign":
>
>      5 -- Message sent by the foreing agent to the home agent

[Hui] Revised, thanks

>

> 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.
>
[Hui] I plan to remove nouce support by only support timestamp.
will make a independent section to describe replay protection, it will be
done soon.

>
> 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.
>
[Hui] Revised thanks,

>
> 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.
>
[Hui] will remove value 3. add value 2 description

>
> 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?
>
[Hui] I think if this message mightbe relayed by FA, then MD will be useful
sometime, to make packet visible clearly., probably HA and CoA is not
needed,
orginal intention is to match notification with acknowledgement.

>
> 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].
>
[Hui] Revised thanks,

>
> 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.
>
[Hui] will revise to say RFC 4917, and will remove revocation.

>
> 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),
>
[Hui]revised, thanks,

>
> 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.
>

[Hui] Revised, thanks

>
> 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.

[Hui] thanks for your input, will revise to ask FA to glean identification
field of RRP.

>
> 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?

[Hui] plan to add the descrition in section 5.1

>
>
> 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.
>
[Hui] I will append a code field for GNA.

>
> 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.
>
[Hui] revised , generically covered, will resend the GNM message.

>
> 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.
>
[Hui] remove revocation to remove the concrn.

>
> 19) 5.1. Typo "notificaiton".  There are other typos that can be checked
> later.
>
[Hui] revised and thanks

>
> 20) 5.2. Not clear how this is different from revocation message with
> generic message string extension?
>
[Hui] will remove revocation support

>
> 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?
>
[Hui] I will append a code field for GNA. and describe the sync issue.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Subtype     |      MD       |     code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
code

      A value indicating the result of the Generic Notification Message.
      See below for a list of currently defined Code values.

   Notification suceessful

      0 -- notification accepted

   Notification denied by the home agent

      128 -- reason unspecified
      129 -- administratively prohibited
      130 -- insufficient resources
      131 -- mobile node failed authentication
      132 -- foreign agent failed authentication
      133 -- notification Identification mismatch

   Notification denied by the foreign agent

      64 -- reason unspecified
      65 -- administratively prohibited
      66 -- insufficient resources
      67 -- mobile node failed authentication
      68 -- home agent failed authentication
      69 -- notification Identification mismatch

   Notification denied by the mobile node

      192 -- reason unspecified
      193 -- administratively prohibited
      194 -- insufficient resources
      195 -- mobile node failed authentication
      196 -- home agent failed authentication
      197 -- notification Identification mismatch

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

[Hui] will describe it and add a reference.

>
> Kent
>

Thanks kent again.