RE: Comments on mip6-mn-auth-option-02.txt

Charlie -

Regarding the open item of changing the Replay Protection option to
Timestamp option, I don't have much problem with that. I can do that in this
update. I think the sequence and nonce based options are not the same though
(well we have not defined nonce option here). The nonce can be longer than
16 bits, for one. But that is another issue.

Also, yesterday, I changed SPI to 16 bits. I would revert back to 32 bits.
One of the reasoning being 32bits is the general length of SPI in almost all
protocols. If we use this option just like in Mobile IPv4 and implementation
index the shared-key based SA using the SPI (on a per HA basis), then
probably such implementations will need 32-bit index anyway.

Please review the version I mailed yesterday evening and let me know.

-a 

> -----Original Message-----
> From: charliep <at> darkstar.iprg.nokia.com 
> [mailto:charliep <at> darkstar.iprg.nokia.com] On Behalf Of 
> Charles E.Perkins
> Sent: Tuesday, January 04, 2005 11:51 AM
> To: alpesh
> Cc: 'Mobile IPv6 Mailing List'
> Subject: Comments on mip6-mn-ident-option-00.txt
> 
> 
> Hello Alpesh,
> 
> Thanks for your quick response to my comments on the MN_IDENT 
> draft.  I did not know there was a later draft.  I have 
> checked my comments below on the "Authentication Protocol" 
> draft against the latest revision of that document.
> 
> In section 1:
>   = delete "using protocols like IKEv1"
>   = replace "The conclusion drawn thereby is"
>              by "This indicates"
>   = paragraph 3, 2nd sentence: "hosts" disagrees
>              with "its"
>   = delete "It should be noted that it does not imply that"
>        In fact, "It should be noted ..." should always be
>        deleted.  (If it's in the spec, it should be noted!)
>   = replace "however" by "still" after "Home agents".
>   = Might be a good idea to mention that this option
>     is meant to resemble a similar feature in Mobile IPv4.
> 
> Section 4:
>   = explain abbreviations.  Also note that
>     AAAH is never specified in any Mobile IPv6 document,
>     so a citation and/or explanation is needed.
>   = The mobile node can use the authentication option
>     without using any Mobile Node identifier option.
>     There is no reason to disallow use of the IPv6
>     address as the identifier.  In fact, I would think
>     it is preferable on almost all counts, except when
>     indicated otherwise for adherence to legacy
>     implementations.
>   = insert "additional" before "replay"
>   
> Section 5:   
>   = The SPI field should be optional, and controlled by
>     subtype (since you have the handy subtype field there).
>     It's a rare case (perhaps, very very very rare) when
>     there will be more than one security association 
>     between mobile node and home agent.  When there's
>     only one, the SPI field is not needed. 
>   = The packet format might well be tagged as "Figure 1"
>     for convenient reference.
>   = I don't see why 32-bit SPIs are needed anyway, even
>     if one wanted an SPI field.  When are there going to
>     be 4 billion different security associations?
>   
> Section 5.1:
>   = First sentence: replace "Section 5" by, say, "Figure 1"
>   = third paragraph: need cross-reference for MN-AAA auth.
>     option
>   = replace "till (including)" by "up to and including"
>   = "First" needs definition, even though it's trivial.
>   
> Section 5.1.1:
>   = First sentence must specify what KIND of security
>     association is shared.  Isn't it possible for IPsec
>     to be used with shared keys?
>   = Second sentence: this should be contingent on how
>     the Binding Update is secured, not the existence of
>     an IPsec SA.  Why can't the mobile node have both
>     kinds of security association? 
>   = Next paragraph: reword the second sentence.  If
>     the error is returned, that's not "discarding".
>     If it isn't returned, then O.K.  How about,
>     "If no SA, then discard; otherwise ..."
>     
> Section 5.2:
>   = replace "Section 5" by "Figure 1"
>   = Fourth sentence: last word should be pluralized.
>   = replace "till (including)" as before
>   = The term "AAA attributes" needs definition or,
>     at least, a citation.
> 
> Section 5.2.1
>   = Shouldn't section 5.2.1.1 be incorporated into
>     this instead of being maintained as a singleton
>     short subsection?
>   = The operation of HAAA is out of scope for this
>     document, so the paragraph needs to be rewritten,  
>     or else a normative citation inserted.  Perhaps  
>     you could use the phrase, "authenticated by an
>     entity external to the HA".  However, I am not 
>     sure why this detail needs to be specified at  
>     all within this draft.  In fact, the same  
>     architecture could be used for Mobile IPv6
>     whether or not the HA uses the authentication
>     option, IPsec, or whatever.
>   
> Section 5.3
>   = delete sentence starting "This MAY need ..."
>   = delete "responding"
> 
> Section 6:
>   = I think it would be better to reorganize this as
>     a "timestamp" option.  The other kind of potential
>     replay protection might be nonce-based, but that
>     does not provide any benefits compared to the base
>     sequence numbering scheme as far as I can tell.
>     Plus, if the sequence number works for most designs
>     in which the values are stored with the mobility
>     security association, then there won't be much
>     pressure anyway for additional schemes.
> 
>     If this is done, there would not be a need for
>     the "subtype" field, unless you want to provide
>     for formats defined other than for RFC 1305.
> 
> Section 6.1
>   = The timestamp processing needs a parameter
>     for "close enough"
>   
> Section 8:
>   = IANA services are needed for the specification,
>     not the document.  In fact, maybe IANA will never
>     see this document, but instead a later revision.   
>     
> Section A.
>   = It is not unreasonable for clique of home agents
>     to share information about the sequence number 
>     used by a mobile node, any more than it is 
>     unreasonable for them to share information about
>     the mobility security association used with that
>     mobile node.
>   = In the third paragraph, it is suggested that some
>     home agents might not cache information about the
>     sequence number used by a mobile node.  This would
>     be a violation of RFC 3775, since then such a home
>     agent could not adequately guard against replays
>     of old sequence numbers.
>   = Same paragraph -- the sequence number does provide
>     protection against replay attacks, unless the
>     home agent incorrectly discards the value of the
>     sequence number used by a mobile node.  This does
>     not depend on whether or not the authentication
>     option is used.
> 
> 
> Other editorial:
> 
> - Use "Binding Update" instead of "Binding update",
>   "Mobile Node" instead of "Mobile node", and so on.
> - Use "option" instead of "extension"
> 
> Regards,
> Charlie P.
>