Re: [mobile-ip] Last Call: Registration Revocation in Mobile IPv4 toProposed Standard

["Steven M. Glass" <Steven.Glass@sun.com>]

    Henrik,

    Apologies to you, and the WG for the delayed turn-around for this.  
Madhavi and I have been discussing, and she sent me her last comments 
on Monday, but I've been too swamped to once again make it all the way 
through them until now (so if there's blame, blame me).  These comments 
are both of ours combined (except where I've used the work "I").


On Tuesday, March 4, 2003, at 05:38  PM, Henrik Levkowetz wrote:

> I'm aware that this is very late in the game, for some reason I didn't
> notice the WG last call on the document. Apologies.

   Yes, this is quite late, though we'll do what we can.  You bring up 
some good points/clarifications, which we address below.


> 	I would like to mention these major comments first:
>
> 	1. The Revocation Message is actually a special case of a
> Notification Message, and would be better defined in two parts; a
> Registration Revocation extension and a Notification Message to carry
> it.
>
> 	2. The same goes for the Revocation Acknowledgement Message, it
> would be better defined as an Registration Revocation Ack extension,
> and
> a general Notification Acknowledgement Message.

    The arrival of an IP packet on our UDP port is a sort of 
notification.  We modeled the new messages for revocation after the 
registration messages, which could have also been 'notification' and 
'registration extension'.  The "Revocation Extension" and "ACK 
Extension" would likely look exactly as they do now (save the replay 
that could be in any generic notification message), though inserting 
something akin to 'notification message' between UDP and what we have 
would only lengthen the entire packet.  Since we already have something 
to model after, we think it's best to stick with what we have.


> 	3. Is it really a good idea to introduce a different replay
> protection Identifier in these messages, compared to the original
> Registration Request and Registration Reply messages? It gives 
protocol
> and implementation complexity, and I've not seen a weighty reasoning
> supporting such a change. I'd strongly suggest we keep the same
> Identification field as in RFC 3344.

    The ID field of 3344 is useful for replay detection between the MN  
and HA, but for various reasons already hashed out, it's not 
generically useful in this case, particularly in cases where multiple
bindings are being revoked with one message.  This has been extensively 
discussed on email...please check the archives for discussions on the 
replay mechanism.  Also, if you look at section 7.2 you'll see a 
discussion leading to the recommendation for challenge-response use on 
the FA which is derived from a related problem with the FA relying on 
the IDs of registration-reply.

That said, we've adopted a system analogous to that in 3344 with 
time-stamps, which seems to be the simplest way to go while providing 
the necessary granularity.


> 	4. The inclusion of Home Address Domain and Foreign Address
> Domain fields concurrently, and mask bits to use them concurrently,
> opens up for DoS attacks which is not at all the intention of the
> authors. Some clarification has been made in the latest draft compared
> to earlier versions, but the mere existence of parallel home address
> domain and foreign address domain fields seems an invitation to 
attack.
> The Home Address Domain is intended for use by FAs, but if
> it were to be used by a rouge HA, and if the FA implemented the
> functionality to revocate bindings based on their HA subnet, then
> a HA might revoke the bindings of any visiting MN from any part of
> the internet. This is not the intention, but I believe it would be
> better to set up the message format so that it is simply not possible.

    The need for clarification here is a good point, as the risk to an 
implementor that doesn't understand the scope of potential rouge 
revocations is quite high.  We do state that the set of revoked 
bindings can only be those that were being serviced by the revoking 
agent (which is certainly implied by the 'FYI' nature of revocation 
messages), and go into a bit more detail, but it needs to be crystal 
clear.  The need for this was initially designed for use by FAs, then 
symmetrically extended for HAs; the need to be able to revoke multiple 
MNs at one time came from specific requests.

We will add text to sections on agent behavior and Security 
Considerations to tighten this up.  Basically, the receiving agent must 
be able to verify the IPsrc of the packet in such a case.  For Agents
that don't have access to the IPsrc address of the revocation, they 
should carefully consider whether they want to use the mask behavior.  
Note that in the security section, we recommend that strong
authentication (e.g., IPSEC) be used when using the mask.


> 	5. The prefix-length extension which the draft proposes to use
> in the MIP revocation messages is defined as an extension of ICMP
> Router
> Discovery messages, it is *not* defined as an MIP control message
> extension. So if this extension is to be used, it must be specified in
> an IANA considerations section that it must be given an extension
> number
> from the MIP control message extension number space.  Additionally, I
> don't believe that this is the only conceivable future need for a
> prefix-length extension, so the extension should be explicitly named
> and
> numbered as a Registration Revocation Prefix-length extension.

    We've been asked to do this, and it's been de-prioritized behind 
this response, but it IS coming soon.


> 	6. Checking the identifier field to protect from replay attacks
> is discussed both in section 3.5 and in section 7.2, but neither place
> gives excact rules for this checking, which may lead to implementation
> differences and mistakes. I'd like it to be spelled out if any value
> different from the previously seen identifier are acceptable, or if
> a value *greater* than the previously seen identifier is required (or
> some other logic?)

OK...we will modify the appropriate text.


> ----
> Full comments except for language comments:
> ----
>
>
> HENRIK: My comments are marked like this
>
>> 3.1  Advertising Registration Revocation Support
>>
>>   Mobility agents can advertise their support of registration
>> revocation
>>   with a modification to the Mobility Agent Advertisement extension
>>   described in [1].  An 'X' bit is introduced to indicate an agent's
>>   support for Registration Revocation.
>>
>>       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      |    Length     |        Sequence Number        
|
>>      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |    Registration Lifetime      |R|B|H|F|M|G|r|T|X|  reserved   
|
>>      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |                  zero or more Care-of Addresses               
|
>>      |                              ...                              
|
>>
>> 	  X   The mobility agent supports Registration Revocation
> HENRIK: The particular position shown here for the 'X' bit is actually
>  	already taken by the 'U' bit of MIPv4 NAT traversal. The figure
>  	should be adjusted accordingly:
>  	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  	|    Registration Lifetime      |R|B|H|F|M|G|r|T|U|X| reserved  |
>  	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

OK.

> ...
>
>> 3.2 Revocation Support Extension
>>
>>   The Mobile IP revocation support extension indicates support of
>>   registration revoction, and so MUST be attached to a registration
>>   request or registration reply by any entity that wants to receive
>>   revocation messages.  Normally, this is either a foreign agent, or 
a
>>   home agent, however a co-located mobile node MAY also include a
>>   revocation support extension in its registration request.  A 
foreign
>>   agent advertising the 'X' bit on the link on which the registration
>>   request was recieved, and who has a security relationship with the
>>   home agent identified in the same registration request, MUST attach
>> a
>>   revocation support extention to the forwarded registration request.
>>   A home agent that receives a registration request which does not
>>   contain a revocation extension SHOULD NOT include a revocation
>> support
>>   extension in the associated registration reply.
>>
> HENRIK: The behaviour for MNs which are *not* operating in co-located
>  	mode should be defined more clearly. Either that MNs registering
>  	through a foreign agent may attach this extension, and the home
>  	agent must ignore it in this case, or that an MN must not attach
>  	this extension in this case. The latter choice is cleaner, I
>  	believe.


      The draft does specify in many places that co-located MNs MAY 
wish to process RECEIVED revocation messages, but that MN's MUST NOT 
send revocation messages.  I don't know what clarifications are needed. 
 The type is defined as skippable.  Either the HA recognizes it [as 
acceptable in this context, and then ignores it], or not.  Implementors 
can do what they like, but if I was an HA, and I saw a registration 
request with a revocation support extension in the MN-HA portion of the 
packet, then rather than return an error, I'd just ignore it, and 
simply not including a revocation extension in the HA-MN portion of the 
registration reply gets the message through, too.


>>   The format of the revocation support extension is based on the
>>   Type-Length-Value Extension Format given in [1] and is defined as
>>   follows:
>>
>>       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      |     Length    |         Timestamp ...
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>> 	Timestamp (continued)        |I|M|      Reserved            |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>>
> HENRIK: If I were to implement this on a machine with 4-byte 
alignment,
>  	I'd *really* appreciate it if the 32bit timestamp field was better
>  	aligned. Please?
>  	 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      |     Length    |I|M|      Reserved             |
>  	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  	|                          Timestamp                            |
>  	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The reason for word-alignment was to leave the flags field open in case 
it needed expansion (the purpose behind a 'length' field, no?  I'll be 
the first to admit I'd be at a loss to think of even a single 
additional flag, but that's what we said back in '96 with the 
registration flags!  There are many protocols that word-align.  It's 
hard to satisfy all, e.g. SPARC would want 64bit alignment.


>> 	  Type
>> 		  Skippable. To be assigned by IANA.
>>
>> 	  Length
>> 		  Length (in bytes, currently 8).  Does NOT include Type
> HENRIK: s/currently 8/currently 6/

Yes!  Thanks for catching this.


>> 		  and Length fields(in accordance with section 1.9 of
>> 		  [1]).  This allows for a longer extension length
>> 		  should more bits be required in the future.
>>
>> 	  Timestamp
>> 		  Current 4-byte timestamp of the mobility agent.  This
>> 		  is used to identify the ordering of registrations as
>> 		  they're forwarded by the agent, how they relate to the
>> 		  sending of any revocation messages, and to identify
>> 		  the approximate offset between the clocks of the
>> 		  mobility agents providing support for this binding..
>>
>> 	  'I' Bit
>> 		  This bit is set to '1' by a mobility agent to indicate
>> 		  it supports the use of the 'I' bit in revocation
>> 		  messages (section 3.3).
>>
> HENRIK: 1. Maybe at least the name of the section 3.3 'I' bit should 
be
>  	given here, to aid in understanding of what this is for?
>  	2. Maybe this bit should be called 'i' to distinguish it from
>  	the section 3.3 'I' bit?

Using 'i' doesn't work as the precedence has been set (e.g. see the 'v' 
flag in 3344) that lower-case represents deprecated flags.  How about 
"(see section 3.3)" as the 'I' bit is only a piece of the information 
that section is giving.


>> 		  When sent by a foreign agent in a registration request:
>>
>> 		  If set to 1, indicates to the home agent that the
>> 		  foreign agent is willing to have the 'I' bit as set by
>> 		  the home agent in the revocation process determine
>> 		  whether the mobile node is informed of the revocation,
>> 		  or not.
>>
> HENRIK: Hard to read. I'd propose:
>  			   ... is willing to have the home agent use the
>  		  'I' bit in the revocation process to determine whether
>  		  the mobile node should be informed of the revocation or
>  		  not.

OK.

> ...
>
>> 	  Reserved
>> 		  Reserved for future use.  MUST be set to 0 on sending,
>> 		  MUST be ignored on receiving.
>>
>>   When appearing in a registration request, or registration reply, 
the
>>   Mobile IP registration support extension MUST be protected either
>> by a
>>   foreign-home authentication extension, a mobile-home authentication
>>   extension, or any other equivalent mechanism [1], e.g. via AAA [A],
>>   [B], or perhaps IPSec.  If the extension appearing in either of
>> these
>>   registration messages is NOT protected, the appropriate action as
>>   described by [1] MUST be taken.  This is due to the security risks
>> as
>>   described by Section 7.
>>
> HENRIK: I'd prefer to have the appropriate action spelled out, or at
>  	least have references to the appropriate sections in 3344. (For
>  	the home agent, 3.8.2.1 says return reg. failure, for the
>  	foreign agent 3.7.3.1 says silently discard.)

Since the behavior is dictated by 3344...we'd rather just cite the 
appropriate sections rather than duplicate it here.


> ...
>
>> 3.3  Registration Revocation Messages
>>
> HENRIK: A general comment on this section: I see this message as a
>  	special case of a notification message. It would be better
>  	defined in two parts; a Registration Revocation extension and a
>  	more general Notification Message to carry it.

    See previous 'notification message' comment.


>>   A revocation message is sent by a mobility agent to inform another
>>   mobility agent, or co-located mobile node, that it is revoking the
>>   binding of a[t least one] mobile node.
>>
>>   The format of revocation message is analogous to registration reply
>>   messages from [1].
>>
>>      IP fields:
>>
>> 	  Source Address       In the case of the home agent issuing the
>> 			       registration revocation, the address
>> 			       registered with the care-of address as
>> 			       that of the home agent.
>>
>> 			       In the case of the foreign agent issuing
>> 			       the registration revocation:
>>
>> 			       If the registration being revoked is NOT
>> 			       for a co-located mobile node, the address
>> 			       registered with the home agent as the
>> 			       care-of address.
>>
>> 			       In the case of the revocation of a
>> 			       co-located mobile node, any of the
>> 			       addresses of the foreign agent associated
>> 			       with the foreign agent NAI which MUST
>> 			       have been included in the most recent
>> 			       registration request to the home agent.
>>
> HENRIK: This doesn't make sense to me. When the mobile node is
> operating
>  	with a co-located care-of address, there is no foreign agent
>  	involved, no?

...unless the 'R' bit was set in the FA advertisement (in which case 
the MN's co-located *and* going through an FA).


>> 	  Destination Address  In the case of the home agent issuing the
>> 			       registration revocation:
>>
>> 			       In the case where the revocation is not
>> 			       for a co-located mobile node, the address
>> 			       identified as the care-of address of the
>> 			       mobile node.
>>
>> S. Glass, M. Chandra      Expires August 2003                   [page
>> 7]
>> 
>> Internet Draft   Registration Revocation in Mobile IPv4    February
>> 2003
>>
>> 			       In the case where the home agent is
>> 			       notifying the foreign agent servicing a
>> 			       co-located mobile node, any of the
>> 			       addresses associated with the NAI of the
>> 			       foreign agent included in the most recent
>> 			       approved registration request.
>>
> HENRIK: Again, this doesn't make sense to me. There's no foreign agent
>  	involved when the mobile node is operating with a co-located
>  	care-of address. ??

Ditto as above.


>> 			       In the case of the foreign agent issuing
>> 			       the registration revocation, the address
>> 			       registered as that of the home agent by
>> 			       the mobile node whose registration is
>> 			       being revoked.
>>
>>      UDP fields:
>>
>> 	  Source Port          variable
>> 	  Destination Port     434
>>
>>      The UDP header is followed by the Mobile IP fields shown below
>>
>>       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      |     Mask      |I|          reserved           
|
>>      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |                          Home Address                         
|
>>      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |                       Home Domain Address                     
|
>>      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |                     Foreign Domain Address                    
|
>>      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |                      Revocation Identifier                    
|
>>      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
> HENRIK: This message is going to carry extensions, as described
>  	later. To illustrate this, it really would be nice if the figure
>  	used the same form as rfc 3344, showing the extensions appearing
>  	after the message header:
>  	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  	| Extensions ...
>  	+-+-+-+-+-+-+-+-

    We had this at one point, and also appended:
  	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  	| Authenticator...
  	+-+-+-+-+-+-+-+-

    Since this is implied by the MIP core draft(s), we don't have to do 
this here.


> ...
>
>> 	  Home Domain Address
>> 		  The IP address in the home domain to identify which
>> 		  bindings are being revoked.  This can be one of the
>> 		  following: (i) the home agent's IP address, (ii) the
>> 		  subnet address indicating that all mobile nodes using
>> 		  a home agent on the identified subnet are having their
>> 		  bindings revoked.  See Section 3.3.1.  The zero
>> 		  address MUST NOT be used, as discussed in Appendix B.
>>
> HENRIK: This is heavy duty stuff! I think this permits one home agent
>  	which has a security association with the foreign agent to set
>  	a very short prefix-length, and revoke the registrations of MNs
>  	which does not belong to it at all!
>  	Why permit this field to be set to a subnet address? What use
>  	case cannot be handled by use of subnet addresses in the two
>  	previous fields? I guess, because it is intended to be used by
>  	a foreign agent, not by a home agent. But the way it is
>  	specified, it could be solidly dangerous.

    As mentioned in the draft, and above, revocation messages always 
have a finite scope, that is specifically the bindings using the agents 
as their tunnel-endpoints.  Without access to the IPsrc address, an 
agent should seriously consider M-bit support.  We can add more 
clarifying text to this effect.


>> 	  Revocation Identifier
>> 		  Protects against replay attacks.  The revoking agent
>> 		  MUST insert its current 4-byte timestamp running off
>> 		  the same clock as it is using to fill in the timestamp
>> 		  in its revocation extensions.  See section 3.5.
>>
> HENRIK: If indeed it is a good idea to introduce an identifier scheme
>  	that differs from that used in regular registration request and
>  	reply messages, I'd expect a presentation of that reasoning, or
>  	a link to it, at this point. But I'd rather see that the
>  	same identifier scheme and format be used here as in RFC 3344.

    See previous comment.  We do state that the FA must be careful 
about replayed request/reply pairs as the replay-protection in them 
protect only the HA and MN from replays, and recommend FAs use 
CHALLENGE extension.


>>   A registration revocation message MUST be protected by either a
>> valid
>>   authenticator as specified in [1], namely a home-foreign
>> authenticator
>>   if the communication is between home and foreign agents, or a
>>   mobile-home authenticator if the communication is being sent from a
>>   home agent to a co-located mobile node, or another security
>> mechanism
>>   at least as secure, and agreed upon by the home and foreign 
domains,
>>   e.g., IPSec and IKE.  If any agent, or co-located mobile node
>> receives
>>
>>   a registration revocation message that does not contain a valid
>>   authenticator, and is not adequately protected, the revocation
>> message
>>   MUST be ignored, and silently discarded.  See Section 7 for a
>>   discussion on the security considerations involved with sending
>>   revocation messages.
>>
>>   A revocation message MUST NOT be sent for any registration that has
>>   expired, and MAY only be sent prior to the expiration of a mobile
>>   node's registration.  Note, however, due to the nature of datagram
>>   delivery, this does not guarantee these messages will arrive before
>>   the natural expiration of any binding.
>>
>>   An agent MUST NOT send more than one revocation message with the
>> same
>>   value in the home address field per second.
>>
>>   An agent MUST NOT send more than one revocation message or
>>   registration message per second for the same binding.  Note this
> HENRIK: s/or registration message//
>  	- don't specify the registration message send frequency here,
>  	leave it to 3344 (or an update of it).

    It's specified here because they're intertwined, that is this draft 
updates the behaviour in 3344 with regards to how many registrations 
*AND* revocations can be sent per binding per second.


>>   updates [1] by including revocation messages in the limit specified
>> in
>>   [1] that an agent MUST NOT send more than one registration message
>> per
>>   second for the same binding.
>>
>>   An example of the use of revocation messages is given in Appendix 
D.
>>
>>
>>
>>
>>
>>
>>
>> S. Glass, M. Chandra      Expires August 2003                  [page
>> 10]
>> 
>> Internet Draft   Registration Revocation in Mobile IPv4    February
>> 2003
>>
>> 3.3.1  Revocation Mask
>>
> HENRIK: The use of the word 'Mask' for this may be slightly
>  	unfortunate, as it is easily associated with a subnet mask,
>  	which it apparently is not.

    Right...it is really a 'flag-mask'.  Mask was used, as in 'masking' 
the mask field, e.g. if (mask & F_DOMAIN) f_domain(packet).

    Unless a much better terms comes up, we should leave it as is.


> HENRIK: In general on the revocation mask and addresses: I think the
>  	specification would be 	noticably simpler, and noticeably less
>  	insecure, if the home domain address and foreign doman addres
>  	were collapsed into one field, a Domain Address field which
>  	would be interpreted according to who is the sender and
>  	receiver.

    There isn't any less security here.  All three address fields are 
included to make it akin to registration requests which contain all 
three, and because in some cases it's more efficient to build 1 
revocation message, and send it to two different HAs.  Also, this has 
built-in overlapping private address support - both domains may be 
using 10.0.0.0/24 behind their 'global' addresses.  Having two separate 
address fields for home and foreign domains makes it more clear what's 
being expressed.


>>   The use of the revocation mask in the revocation message is
>> OPTIONAL.
>>   The revocation mask MUST NOT be used unless the 'M' bit was set to
>> '1'
>>   in the last revocation extension received from the agent peer for
>> all
>>   bindings identified by the revocation message.  When it is not 
being
>>   used, the revocation mask MUST be set to all zeros.  The
>> registration
>>   revocation message uses a non-zero mask to indicate the "extent" of
>>   the revocation is more than a single binding.  The mask is used in
>>   combination with the address fields defined above to identify
>> certain
>>   special cases when multiple bindings can be revoked with a single
>>   revocation message.  The following bit-values are defined.  Note 
the
>>   four low-order bits apply to addresses, and the four high-order 
bits
>>   apply to NAIs.  For those applying to addresses, prefix length
>>   extensions are required.  For those applying to NAIs, NAI 
extensions
>>   are required.
>>
> HENRIK: Note that the prefix-length extension is defined as an
> extension
>  	of ICMP Router Discovery messages, it is *not* defined as an MIP
>  	control message extension. So if this extension is to be used,
>  	it must be specified in an IANA considerations section that it
>  	must be defined as a MIP control message extension.
>  	Additionally, I don't believe that this is the only conceivable
>  	future need for a prefix-length extension, so this should be
>  	explicitly named as a Registration Revocation Prefix-length
>  	extension.

    I'm not exactly sure if we'd be violating the code value for 
prefix-length extensions, though I'll find out and add the necessary 
text to the IANA requirements section.  (Note that I don't think we're 
the first people to suggest this, though I haven't the time to pull up 
a specific reference for you).


> HENRIK: For both security reasons and for correct handling of private
>  	home and foreign addresses, it is vital in the following that
>  	the mask value is conditional upon the requesting home agent
>  	address matching the home agent address of the revoked
>  	registrations. I think this must be pointed out more explicitly
>  	here and below. It is mentioned a a note further down, but I
>  	don't think that's enough.

    We do, stating the scope of registrations MUST be those using the 
revoking agent as a tunnel endpoint, though the point is taken that 
maybe we need to clarify a bit.


>>      Value   Meaning
>>      -----
>> -----------------------------------------------------------
>>
>>       0x01   Applies to all bindings where the mobile node home
>> address
>> 	     belongs to the same subnet as the address appearing in the
>> 	     home address field.  The address appearing in the home
> HENRIK: s/field./field and whose registered home agent is the same as
> given in the home
>  	domain address field./

If we really have to be specific in each one of these, then - s/address 
field./field and whose registered care of address is the same as given 
in the foreign domain field.  However, the entire section is to viewed 
as a collection of ANDs (if you like), and thus doesn't seem necessary 
to repeat this over and over and over and over....


>> 	     address field MUST either be that of a registered mobile
>> 	     node, or a subnet address.  The issuing agent MUST include
>> 	     a prefix-length extension defined by [1] appearing after
>> 	     the revocation message to indicate the bits of address
>> 	     effected.
>>
>> 	     e.g. revoke: 10.1.1.128, prefixLen: 25 means all mobile nodes
>> 	     whose addresses fall within the range 10.1.1.128 - 10.1.1.254
> HENRIK: ADD: and whose registered home agent is the same as given in
> the home
>  	domain address field.

    Ditto.


>> 	     and revoke: 10.1.1.129, prefixLen: 25 has the same meaning,
>> 	     but revoke: 10.1.1.0, prefixLen:25 means all mobile nodes
>> 	     whose addresses fall within the range 10.1.1.0 - 10.1.1.127.
> HENRIK: ADD: and whose registered home agent is the same as given in
> the home
>  	domain address field.

     Ditto.


>>       0x02   Applies to all bindings where the registration is using
>> the
>> 	     same home domain address appearing in the Home Domain
>> 	     Address field.  The address appearing in the Home Domain
>> 	     Address field MUST either be the address registered as the
>> 	     home agent address, or a subnet address.  The issuing agent
>> 	     MUST include a prefix-length extension as defined by [1]
>> 	     appearing after the revocation message to indicate the bits
>> 	     of address effected.
>>
>> 	     (e.g. revoke: 10.1.1.240, prefixLen: 28).
>>
>> 	     Note that this address MUST NOT be the zero address, see
>> 	     Appendix B.
>>
> HENRIK: As noted earlier, I'm really doubtful to permitting a subnet
>  	address in this case, if this mask field can be set by a rouge
>  	HA.

    Note, too, that such a rogue would have to have access to the 
secret security bits, and one which does is implied to be trustworthy 
(or e.g. suffer legal repercussions).  Should a trusted HA try to DoS 
another HAs bits, then as noted earlier, access to the IP header solves 
this problem.


>> S. Glass, M. Chandra      Expires August 2003                  [page
>> 11]
>> 
>> Internet Draft   Registration Revocation in Mobile IPv4    February
>> 2003
>>
>>       0x04   Applies to all bindings where the care-of address 
belongs
>> 	     to the same subnet as the address appearing in the foreign
>> 	     domain address field.  The address appearing in the foreign
> HENRIK: s/field./field and whose registered home agent is the same as
> given in the home
>  	domain address field./


    Ditto [as previous-2].

>> 	     domain address field MUST either be the co-located address
>> 	     belonging to a mobile node, or a subnet address.  The
>> 	     issuing agent MUST include a prefix-length extension as
>> 	     defined by [1] appearing after the revocation message to
>> 	     indicate the bits of address being effected.
>>
>> 	     (e.g. revok: 10.1.1.192, prefixLen: 26).
>>
> HENRIK: Is this meaningful?

    Yes.  Why/how its ambiguous?


> HENRIK: ADD: and whose registered home agent is the same as given in
> the home
>  	domain address field.

    Ditto [as previous-2].

>>       0x08   Applies to all bindings where the registration is using
>> the
>> 	     same foreign address appearing in the foreign domain
>> 	     address field.  The address appearing in the foreign domain
> HENRIK: s/field./field and whose registered home agent is the same as
> 		 given in the home domain address field./

    Ditto [as previous-2].


>> 	     address filed MUST either the address registered as the
>> 	     foreign agent address, or a subnet address in which case
>> 	     the issuing agent MUST include a prefix-length extension as
>> 	     defined by [1] appearing after the revocation message to
>> 	     indicate the bits of address being effected
>>
>> 	     (e.g. revoke: 10.1.1.224, prefixLen: 27).
>>
>>       0x10   Applies to all bindings within the same administrative
>> 	     domain as the mobile node.  The issuing agent MUST include
>> 	     the NAI of [one of] the mobile nodes whose registration is
>> 	     being revoked in an NAI extension, appearing after the
>> 	     revocation message.
>>
> HENRIK: How is 'the same administrative domain' determined? Reference?

    We can add the reference.  It's based on the same definitions used 
in the NAI draft, reference [4] which is referenced by [A] and/or [B] 
as well.


>>       0x20   Applies to all bindings with the same administrative
>> domain
>> 	     as the home agent.  The issuing agent MUST include the home
>> 	     agent NAI in an NAI extension appearing after the
>> 	     revocation message.
>>
> HENRIK: It appears to me that this should only be sent by a home 
agent.
>  	Yes?

     Perhaps, but your implication is that you want/we need to specify 
that.  If it's not possible for it to be used by the foreign domain at 
this time, then a foreign domain can't make it meaningful at this time, 
so restricting it now is unnecessary.  Should the foreign domain 
be[come] able to use this field
[in the future], then why restrict it now?


>>       0x40   Applies to all bindings with the same administrative
>> domain
>> 	     as the care-of address.  The issuing agent MUST include the
>> 	     NAI from the care-of domain in an NAI extension, appearing
>> 	     after the revocation message.
>>
> HENRIK: It appears to me that this should only be sent by a foreign
>  	agent or MN with co-located care-of address. Yes?


     Ditto.


>>       0x80   Applies to all bindings with the same administrative
>> domain
>> 	     as the foreign agent.  The issuing agent MUST include the
>> 	     foreign agent NAI in an NAI extension appearing after the
>> 	     revocation message.
>>
> HENRIK: It appears to me that this should only be sent by a foreign
> agent.
>  	Yes?

     Ditto.


>>   When multiple flags are set, the corresponding prefix-length and 
NAI
>>   extensions MUST appear in the same order as the flags appearing in
>> the
>>   mask field of the revocation message.  This means NAI extensions
>> MUST
>>   proceed prefix length extensions.  For example, if the 0x01 and 
0x02
>>   bits are set, the first prefix length extension identifies the
>> prefix
>>   to be used with the care-of address to identify the care-of address
>>
>>
>> S. Glass, M. Chandra      Expires August 2003                  [page
>> 12]
>> 
>> Internet Draft   Registration Revocation in Mobile IPv4    February
>> 2003
>>
>>   subnet, and the second prefix length extension is to identify the
>>   prefix to be used with the home address to identify the home 
address
>>   subnet.  If the 0x01 bits and 0x20 bits are set instead, the home
>>   agent NAI extension MUST proceed the home address prefix length
>>   extension.
>>
> HENRIK: This becomes convoluted and not terribly obvious, due to the
>  	dependency on bit-order representation for the mask. I think it
>  	would be better all around if the bits were given individual
>  	names instead of being treated as a composite number.

    Using the prefix-length extensions in this manner is directly akin 
to agent advertisements in 3344.  An agent can include multiple 
addresses in the agent advertisement extension, and then MUST append 
multiple prefix-length extensions so the first such extension applies 
to the first address, and so on.


> ...
>
>> 3.4  Registration Revocation Acknowledgment Message
>>
> HENRIK: A general comment on this section: I see this message as a
>  	special case of a notification acknowledgement. It would be
>  	better defined in two parts; a Registration Revocation
>  	Acknowledgement extension and a more general Notification
>  	Acknowledgement Message to carry it.
>
>>   A revocation acknowledgment message is sent by mobility agents or
>>   co-located mobile nodes to indicate the successful receipt of a
>>   revocation message.
>>
>>   The format of revocation acknowledgment message is analogous to the
>>   revocation message.
>>
> HENRIK: No, there's a Length field here which neither Registration
>  	Request, Registration Response nor Registration Revocation
>  	Messages have. What is the purpose of that?

    Good catch!  We simply don't need it (and honestly don't know how 
it got in there).


> ...
>
>>      The UDP header is followed by the Mobile IP fields shown below:
>>
>>       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      |     Length    |I|         reserved            
|
>>      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |                          Home Address                         
|
>>      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |                     Revocation Identifier                     
|
>>      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
> HENRIK: This message is going to carry extensions, as described
>  	later. To illustrate this, it really would be nice if the figure
>  	used the same form as rfc 3344, showing the extensions appearing
>  	after the message header:
>  	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  	| Extensions ...
>  	+-+-+-+-+-+-+-+-

    Replied in a previous comment somewhere above...


>>      Type       To be assigned by IANA. (Revocation Acknowledgment)
>>
>>      Length     (in bytes) 10. The length of the revocation
>> acknowledgment
>> 		message in octets, not including Type and Length fields.
>>
> HENRIK: As mentioned above, what is the purpose of the Length field?

    As mentioned above, it's gone!


> ...
>
>>
>>      Revocation Identifier
>> 		Copied from the Revocation Identifier of the revocation
>> 		message for which this acknowledgment is being sent.
>> 		See Section 3.5.
>>
> HENRIK: As mention for the Registration Revokation Message, I'd rather
>  	see that the same identifier scheme and format be used here as
>  	in RFC 3344.

    Doesn't work, and it MUST be akin to the ID of the revocation 
message.  See the archives for the lengthy discussion.


> ...
>
>> 3.5  Replay Protection
>>
> HENRIK: I would expect an excellent motivation here, for using this 
new
>  	format instead of re-using the format described in RFC 3344,
>  	but even better would be to change this to the 3344 timestamp
>  	identifier format.

    It's akin to time stamp identifier format, but with the 1 second 
resolution in the core draft, we didn't see the need for the 64-bit 
partial section resolution.


> ...
>
>> 4.1  Mobile Node Notification
>>
>>   A mechanism which provides a foreign agent a way to actively notify
>> a
>>   mobile node that its binding has been reset already exists in [1],
>>   though it has been overlooked for this purpose.
>>
>>   A brief overview of the mechanics of the sequence number in agent
>>   advertisement from [1] is given so that the mechanism by which the
>>   foreign agent 'implies' to the mobile node that its binding is no
>>   longer active is clearly understood.
>>
>>   When a foreign agent begins sending agent advertisements, it starts
>>   with a sequence number of 0, and [monotonically] increments the
>>   sequence number with each subsequent agent advertisement.  In order
>>   for a mobile node to be able to distinguish between a foreign agent
>>   that has simply exhausted the sequence number space from one which
>> has
>>   been reset, and thereby lost the mobile node's binding information,
>> a
>>   foreign agent sets the sequence number to 256 instead of rolling to
>> 0.
> HENRIK: ... when it increments the counter past its maximum value.


OK, it couldn't hurt us to add this bit here for clarity.


> ...
>
>>   Agent Advertisements unicast to a mobile node MUST be sent as
>>   described in [1] in addition to any methods currently in use on the
>>   link to make them secure or authenticatable.  Such mechanisms are
>>   highly desirable to protect from denial-of-service attacks.
>>   Implementors and deployers may wish to see section 7 of this
>> document,
>>   and [5].
> HENRIK: This doesn't read well, could it be reformulated more clearly?

    Not clear on your confusion. Can you suggest text?

> ...
>
>>   When a revocation message is being sent to a foreign agent, and the
>>   use of the 'I' bit was negotiated in the registration process, the
>>   home agent MUST set the 'I' bit to 1 if the home agent would like
>> the
>>   foreign agent to inform the mobile node of the revocation.
>> Conversely,
>>   if the home agent does not want the mobile node notified, it MUST
>> set
>>   the 'I' bit to 0.
> HENRIK: Maybe 'must' would be just as good as 'MUST' in this 
paragraph?

    By definition it's not, that is "MUST" comes with a precise 
definition with implication to implementors, where "must" does not.


> ...
>
>>   If notifying the mobile node by the methods described in Section
>> 4.1,
>>   the foreign agent MUST set the 'I' bit to '1' in the revocation
>>   acknowledgment to be sent to the home agent, or if not notifying 
the
>>   mobile node, the foreign agent MUST set the 'I' bit to '0'.
>>
>>   The foreign agent may discontinue all Mobile IP services, and free
>> up
> HENRIK: Should this 'may' be a 'MUST'?

    No, since it's really up to the implementation.


>  	s/services,/services at this time,/

    I submit "at this time" is implied, but we can add it.


> ...
>
>> 4.2.3.1  Foreign Agent Responsibilities
>>
>>   If the use of the 'I' bit was negotiated, and the foreign domain
>>   policy of informing the mobile node has not changed since the last
>>   successful registration exchange, the foreign agent MUST NOT inform
>>   any mobile node of its revocation at this time.  Instead, the
>> foreign
>>   agent MUST set the 'I' bit to '1' in the revocation message, 
thereby
>>   asking the home agent to use the 'I' bit in the revocation
>>   acknowledgment to indicate if it should notify the effected mobile
>>   nodes.  If the policy on the foreign domain was to not notify the
>>   mobile node, or if it has changed since the most recent successful
>>   registration, and the foreign agent is no longer able to use the 
'I'
>>   bit, the foreign agent MUST set the 'I' bit to '0', and follow the
>>   policies of the foreign domain with regard to notifying the mobile
>>   node.
>>
>>   To preserve the robustness of the protocol, the recommended default
>> is
>>   that the foreign agent SHOULD inform the mobile node of its
>> revocation
>>   as described in Section 4.1 either before sending the revocation
>>   message to the home agent, just after sending the revocation 
message
>>   to the home agent, or after it receives a revocation acknowledgment
>>   message from the home agent.
> HENRIK: This seems to contradict what was said in the previous
>  	paragraph.

    Not really...it talks about defaults rather than specifics.


> ...
>
>> 4.3.1  The 'R' Bit in Use
>>
>>   If the foreign agent wishes to be able to revoke a mobile node's
>>   registration, it MUST set the 'R' bit in its agent advertisements.
>> A
>>   foreign agent advertising the 'R' bit requests every mobile node,
>> even
>>   one that is co-located, to register with the foreign agent, making
>> the
>>   foreign agent then capable of revoking the mobile node's
>> registration
>>   as it is now privy to the information in the registration request,
>>   namely the mobile node's link address, home IP address, and the
>>   address of the mobile node's home agent.  The foreign agent will
>> then
>>   be capable of unicasting an agent advertisement to the mobile node,
>>   and sending a registration revocation message to the home agent, as
>>   described in Sections 4.1 and 4.2.3.  This makes advertising the 
'R'
>>   bit attractive in domains that wish to have control over registered
>>   mobile nodes, and moreover, sending revocation notification to the
>>   home domain may be a contractual necessity.
>>
> HENRIK: Do you mean "...to the foreign domain may be a contractual
>  	necessity." here? This may need to be expanded or removed.

    No, because the 'R' bit applies only to the FA, so it would have to
use the 'R' bit to intercept registration messages if its relationship
with the home domain requires it to send revocation messages to the
HOME domain.


>>   Enforcement of the 'R' bit is beyond the scope of this document, 
and
>>   when the foreign domain wishes to be able to enforce the 
revocation,
>>   and/or to notify the home domain of revoked registrations, such an
>>   enforcement mechanism is crucial.  Since the co-located care-of
>>   address is by definition topologically correct, the reader must
>>   understand that a co-located mobile node may send the registration
>>   request directly to the home agent, and perhaps receive a
>> registration
>>   reply from the home agent even in the presence of agent
>> advertisements
>>   in which the 'R' bit is set (though this is considered "bad form",
>> and
>>   the 'R' bit is a "hint" to the mobile node that such direct contact
>> is
>>   policed in some way).  In the event a foreign domain wishes to
>> enforce
>>   the revocation of a co-located mobile node's registration, the
>> foreign
>>   domain MUST be able to control the flow of datagrams to, and/or
>> from,
>>   the mobile node.  The easiest way to do this is for local policy to
>>   not provide a mechanism for co-location, or for the foreign agent 
to
>>   simply not accept registration requests from co-located mobile
>> nodes,
>>   though there are enforcement mechanisms available which allow
>>   co-location.
>>
> HENRIK: This paragraph is maybe going a bit too far into the use of 
the
>  	'R' bit in general, I'm not sure that it belongs in this document.

    It's clarification of the previous part of the paragraph.

> ...
>
>>   Upon release of this registration, if revocation support was
>>   negotiated with BOTH the co-located mobile node, and the foreign
>>   agent, revocation messages for this binding MUST be first sent to
>> the
>>   mobile node's co-located care-of address to ensure that they reach
>> it.
>>   This includes the time for any necessary retransmissions should a
>>   revocation acknowledgment not be forthcoming.  A revocation message
>>
>>
>> S. Glass, M. Chandra      Expires August 2003                  [page
>> 28]
>> 
>> Internet Draft   Registration Revocation in Mobile IPv4    February
>> 2003
>>
>>   MUST then be sent to the foreign agent.  If a revocation message 
was
>>   sent to the foreign agent first, there may be no way for a
>> revocation
>>   message to then reach the mobile node.  Also, in order for the home
>>   agent to be able to send a revocation message to the foreign agent,
>> it
>>   is presumed that the source IP address of the most recently 
accepted
>>   registration request is that of the foreign agent, or that the
>>   security association between the home and foreign agents contains
>>   (among other things) the NAI and IP addresses of the foreign agent.
>>
> HENRIK: This is a bit wordy. It is also already covered in 4.2.2.1

    Section 4.2.2.1 covers the specific details for Home Agent 
responsibilities.

    This is also here as a reference for people referring to Section 
4.3.2 specifically for 'D' bit advice.  Yes, related, but more concise.


>> 5.  Error Codes
>>
>>   As the intent of a registration revocation message is not a request
>> to
>>   discontinue services, but is a notification that Mobile IP services
>>   are discontinued, there are no new error codes.
>>
> HENRIK: This seems somewhat superfluous, since there is no error field
>  	in the new messages. It *would* be relevant for generalized
>  	notification and notify acknowledgement fields.

    The point of this section is to make it clear that in this model 
there are no error codes, and why there aren't any error codes.  We 
prefer to keep it in.


>> 6.  Multiple Binding Support
>>
>>   RFC 3344 [1] allows a mobile node to register multiple care-of
>>   addresses with its home agent.  Each one of these bindings is it's
>> own
>>   discrete registration, and hence can be treated as a separate case
>> for
>>   registration revocation.  Consider the situation where a mobile 
node
>>   has multiple care-of addresses registered with a single foreign
>> agent
>>   (either because the mobile node has multiple co-located care-of
>>   addresses on a single link, and the foreign agent has the 'R' bit
>> set,
>>   or because the foreign agent is multi-homed and the mobile node has
>>   registered all these care-of addresses using multiple binding
>> support
>>   [1]).  Either agent can indicate the revocation of all these
>> bindings
> HENRIK: s/Either agent can/Both the home agent and the foreign agent
> may/

     Whatever (unless you mean MAY, in which case I'd have to disagree).


>>   by identifying the mobile node's home address, and home agent
>> address,
>>   and setting the care-of address field to the zero address (and 
their
>>   addresses in the correct places), indicating all care-of addresses
>>   being used by the indicated mobile node that are bound to the agent
>>   identified by this revocation message.
>>
>>   If a foreign agent revokes a particular mobile node's binding(s),
>> the
>>   home agent MAY or MAY NOT then revoke any of the mobile node's 
other
>>   bindings (with other foreign agents).  If a home agent is revoking
>> one
>>   of a mobile node's bindings, it MAY revoke none, or all of the
>> mobile
>>   node's other bindings as it sees fit.  If a home agent decides to
>>   revoke a single binding for a mobile node, the foreign agent MAY
>>   decide to revoke other bindings for the same mobile node as it sees
>>   fit.
>>
> HENRIK: The first part of this paragraph is almost self-evident, and
>  	might be omitted. The last sentence, however, is possiby quite
>  	contentious. I would suggest changing this completely:
>  	"If a home agent decides to revoke a single binding for a mobile
>  	node, the foreign agent MUST NOT on its own decide to revoke
>  	other bindings for the same mobile node."

    The point of all this is to show individual bindings are unrelated.

    The change you suggest is misleading.  Any agent can use any 
criteria for revoking a binding.  If the HA is demonstrating some 'lack 
of confidence' over one binding, the FA is entirely welcome to be 
paranoid, remove the other bindings, and provide [revocation] notice.


>>   The revocation mask is designed to make revoking multiple bindings
>>   easy to specify, be they for multiple mobile nodes, or
>>   multiply-registered mobile nodes, even in situations where network
>>
>>
>> S. Glass, M. Chandra      Expires August 2003                  [page
>> 29]
>> 
>> Internet Draft   Registration Revocation in Mobile IPv4    February
>> 2003
>>
>>   topologies make revoking multiple mobile node bindings difficult to
>>   specify numerically through the use of NAIs.
>>
> HENRIK: ?? numerically through the use of NAIs ?? doesn't parse.


    Meaning: map the NAIs to addresses (as any good SA likely would, 
somehow).


>> 7.  Security Considerations
>>
>>   There are two basic susceptibilities, one in agent advertisement
>>   mechanism, and one relating to unauthorized revocation messages.
>>
> HENRIK: There's potentially a third one having to do with a rouge home
>  	agent requesting a deregistration of mobiles which does not
>  	belong to it, through the use of a home domain address with a
>  	short prefix length and the 0x02 value in the Mask field.

    See previous discussion about scope of revocations (which apply 
only to those bindings which the agent has jurisdiction over).  This is 
therefore not another susceptibility unless the implementation allows 
the peer to exceed its authority.


> ...
>
>>   Revocation messages for single bindings are at least as secure as
>>   registration messages passed between home and foreign agents and
>>   containing home-foreign authenticators as defined in [1].  Thus,
>> there
>>   are no new security threats introduced by the revocation mechanism
>>   than those present in [1] with respect to the compromise of the
>> shared
>>   secret which is used to generate the home-foreign authenticators.
>>
> HENRIK: Except that the replay protection may be weaker due to the
>  	change in the Identifier field.

    Can you clarify?  Why does changing the ID field imply weaker 
protection?  The reason for change is often to make things stronger.  
Here we had to change it to make it work!


> ...
>
>>   The replay protection mechanism used by the revocation messages
>>   defined by this document is designed to protect against both of
>> these
>>   man-in-the-middle attacks.  As a benefit, by using a 32-bit
>> timestamp
>>   it can be more quickly determined if revocation messages are
>> replays,
>>   though the reader is advised to use caution in this approach.  An
>>   agent which receives an authenticated revocation message can 
compare
>>   the Identifier field to that of a previously received revocation
>>   message, and if the timestamp in the new message is found to have
>> been
>>   generated after that of the time-stamp in the last revocation
>> message
>>   received, it can immediately be determined as not being a replay.
>>   Note however that since datagrams are not guaranteed to arrive in
>>   order, it should not be presumed that because the values contained
>> in
>>   an Identifier field are timestamps that they will necessarily be
>>   increasing with each successive revocation message received.  
Should
>>   an implementor decide to base his replay detection mechanism on
>>   increasing timestamps, and therefore increasing Identifier values, 
a
>>   suitable time window should be defined in which revocation messages
>>   can be received.  At worst, ignoring any revocation message should
>>   result in the retransmission of another revocation message, this
>> time
>>   with timestamp later than the last one received.
>>
> HENRIK: This seems somewhat imprecise. What are exact rules for
> checking
>  	the validity of the identifier field?

    We'll add text.


>>   Note that any registration request or reply can be replayed.  With
>> the
>>   exchanging of time-stamps by agents in revocation extensions, an
>> agent
>>   should have a belief that such messages have been delivered in a
>>   timely manner.  For purposes of registration revocation, the
>>   timeliness of a registration packet is simply based on the
>> granularity
>>   of each registration.  Since [1] provides a replay mechanism for 
the
>>   home agent to use, it has a way to tell if the registration request
>>   being presented to it is new.  The foreign agent, however, has no
>> such
>>   mechanism in place with the mobile node.  Foreign agents are 
advised
>>   to continue to consider registrations 'outstanding' until the
>>   associated registration reply is returned from the home agent 
before
>>   using the information in either in its visitor entries.  Even so,
>> this
>>   leaves the foreign agent open to a potential denial of service
>> attack
>>   in which registration requests and replies are replayed by multiple
>>   nodes.  When this happens, the foreign agent could be lead to
>> believe
>>   such registrations are active, but with old information, which can
>>   have adverse effects on them, as well as to the ability of that
>> agent
>>   to successfully use the procedures outlined in this document.
>>   Sufficient protection against this scenario is offered by the
>>   challenge-response mechanism [9] by which a foreign agent generates
>> a
>>   live challenge to a mobile node for the purposes of making sure,
>> among
>>   other things, that the registration request is not a replay.
>>
> HENRIK: This paragraph seems to be more a discussion of RFC 3344
>  	security issues than issues with this document?

    Though it does so specifically with the relation of DoS to 
revocation since now these replays can be including revocation support 
extensions, leading directly to the benefit of [9] (and thank you to 
Pete McCann for pointing this out).


>>   RFC 2794 [4] describes the use of the Network Access Identifier in
>>   Mobile IP.  Its relevant use here is for agents to be able to
>> identify
>>   each other in a revocation message.  In cases where foreign and 
home
>>   domains are going to approve registrations from co-located mobile
>>   nodes (registering with the 'D' bit [1]), and in topologies where
>> the
>>
>>
>> S. Glass, M. Chandra      Expires August 2003                  [page
>> 32]
>> 
>> Internet Draft   Registration Revocation in Mobile IPv4    February
>> 2003
>>
>>   foreign agent is setting the 'R' bit in its agent advertisements
>> [1],
>>   if the agents are going to use their NAIs to identify themselves 
the
>>   security association they share MUST include the IP address the
>>   registration revocation messages are to be sent to, and will be 
sent
>>   from.  For a more involved discussion, see Appendix A.
>>
> HENRIK: IANA Considerations section is missing.

    This section is being drafted...


                               Cheers,
                                   Steve and Madhavi