Subject: [mobile-ip] IESG review of draft-ietf-mobileip-reg-revok-05.txt

From: Thomas Narten <[email-masked]>
Date: Fri, 04 Apr 2003 08:50:17 -0500

The IESG discussed the document yesterday, and the number of issue
raised was pretty small (see below).

But I will say, the IESG as a whole seemed to agree with the comment
"this document is awfully long and complex for a conceptually simple
idea". If there wasn't pressure to get this document out as an RFC in
the short term, I'd be tempted to push back and say "simplify it". I
too, think it has way more text in it than is needed.

In any case, we should push to get the document revised and approved,
as 3GPP2 does need it. Can we get an estimate of when we think a
revised ID will be ready? Can this be done within 1-2 weeks?

Also, Pete McCann did a review of the document and discussion has been
going back and forth on some fine points (which I haven't studied yet)
I wonder if there is a way we could get more of this discussion out
into the open on the mailing list. Or, are the issues purely
editorial?
 
Also, given discussion on problem statement and elsewhere, I wonder if
it would be reasonable to add another line to the acknowledgments
section thanking Pete explicitely for his detailed review during the
IETF last call, as it did uncover some things. We don't get enough of
those reviews, and IMO, it would be good to mention them in the
document. Of course, if others have made such reviews, listing their
names would be appropriate too.

Thomas

Steve:
 3.2: Is there some reason why the "I|M|Reserved" field doesn't come 
 before the timestamp? That would permit the timestamp to be aligned.
 (Or is that not helpful for this sort of TLV?)

 3.5: Delete the phrase "man-in-the-middle" attack -- these aren't. 
 They're "active attacks".

 7.2 is not clear enough on what the mandatory-to-implement security is. 
 It says 

       Revocation messages
       defined in this document which are passed between home and 
	 foreign agents in the revocation process MUST be protected by 
	 either the same foreign-home authenticators defined in [1], or 
	 another authentication mechanism at least as secure and agreed 
	 upon by the end agents, e.g., IPSec and IKE.

 That's not acceptable. Apart from the question of how a home and a 
 foreign agent "agree" upon another mechanism, it doesn't mandate 
 support for [1]'s mechanism (or some other strong-enough mechanism).

 (Earlier comments about MITM attacks apply here, too.)

COMMENTS:
=========
Bert:
 However, I do see (non-compliance with ID-NITS):

 - citation in abstract

 - Page 11:

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

                       (e.g. revoke: 10.1.1.240, prefixLen: 28).

       and there is more of that on following page(s)

       ID-NITS says
           Addresses used in examples should prefer use of fully qualified
           domain names to literal IP addresses, and prefer use of example
           fqdn's such as foo.example.com to real-world fqdn's
           See RFC 2606 for example domain names that can be used
           There is also a range of IP addresses set aside for this purpose.
           These are 192.0.2.0/24 (see RFC 3330). Private addressess that
           would be used in the real world should be avoided in examples. 

 - References not split

Bert:
>From: "Wijnen, Bert (Bert)" <[email-masked]>
 >To: "Steven M. Bellovin" <[email-masked]>,
 >Subject: RE: Evaluation: draft-ietf-mobileip-reg-revok - Registration Revo

 > In message 
 > <[email-masked]
 > om>, "Wijnen, Bert (Bert)" writes:
 > >> Yes No-Objection Discuss * Abstain 
 > >> Bert Wijnen [ ] [ X ] [ ] [ ]
 > >
 > >However, I do see (non-compliance with ID-NITS):
 > >
 > >- citation in abstract
 > >
 > >- Page 11:
 > >
 > > 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
 > > 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.
 > >
 > >
 > > (e.g. revoke: 10.1.1.240, prefixLen: 28).
 > >
 > > and there is more of that on following page(s)
 > >
 > > ID-NITS says
 > > Addresses used in examples should prefer use of fully qualified
 > > domain names to literal IP addresses, and prefer use of example
 > > fqdn's such as foo.example.com to real-world fqdn's
 > > See RFC 2606 for example domain names that can be used
 > > There is also a range of IP addresses set aside for 
 > this purpose.
 > > These are 192.0.2.0/24 (see RFC 3330). Private addressess that
 > > would be used in the real world should be avoided in examples. 
 > 
 > 
 > But the document is talking about IP addresses and prefixes here; I 
 > don't think FQDNs would make any sense.
 > 
 Correct. But there are also IP addresses set aside for such use and
 they are using other IP addresses.

 (I personally can live with it though... I just noticed).

 Bert

Thomas:

abstract has references; my writeup might be a better abstract?

Headers/sections funny; they are way far indented relative to the
text.

>		mobility agents providing support for this binding..

s/.././

> extension, or any other equivalent mechanism [1], e.g. via AAA [A],
> [B], or perhaps IPSec.  If the extension appearing in either of these 

references not consistent ([1] vs. [A])

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

Is this OK?

> Support of the 'I' bit is OPTIONAL.  If a mobility agent does not
> support the specified behavior, it MUST set the 'I' bit to zero.  Note
> that the home agent setting the 'I' bit to '1' in response to a
> revocation extension from the foreign agent in which the 'I' bit was
> set to '0' is undefined, and SHOULD NOT be done.

wording is odd. Just what is the part that is optional.

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

would it make sense to query the WG and see if anyone thinks they will
implement this, or need to? If not, kill it. (seems complex if no one
thinks its needed.)

> Note that the scope of the revocation MUST only apply to the subset of
> bindings between the revoking agent, and the agent receiving the
> revocation message. For example, if foreign agent x.y.z.t sends a
> revocation message to home agent a.b.c.d for mobile node subnet
> a.b.c.0, and sets the revocation mask to 0x01, the home agent MUST NOT
> revoke all of its bindings for mobile nodes on the same home link as
> the revoked mobile node, but only those mobile nodes that are also
> visiting the foreign agent sending the revocation message.

say more about "authorization"? A key question is who is authorized to
make revokations and what bindings do those authorizations cover.

>     - the home agent MUST NOT send more than one revocation per second
>       for a particular binding, or set of bindings,
> 
>     - the time between retransmissions SHOULD fall-back in analogy
>       with the registration guidelines in [1], and

need to ensure exponential backoff.

    4.2.2.3  Co-located Mobile Node Responsibilities

---

From: "Steven M. Glass" <[email-masked]>
Date: Fri, 04 Apr 2003 11:16:03 -0500

Thomas,

     Some quick answers (the others will have to wait for later)...

> too, think it has way more text in it than is needed.

     The original document was quite small, defining a single message 
which applied to a single binding, but it evolved into what we have now 
by combining it with another draft, 'resource release', wanted by 
3GPP2, as well as adding [more] functionality required by the 3GPP2 
folks such as e.g. support for revocation of multiple bindings via a 
single message ('M' bit).

> revised ID will be ready? Can this be done within 1-2 weeks?

     I believe it can.

> into the open on the mailing list. Or, are the issues purely

     They are mostly editorial at this time, though there are a few 
concepts that are not purely editorial which we are debating.  The main 
one is the documents discussion about NAIs which aren't MN NAIs, and 
the document, in its consideration of all edge-cases, references HA 
NAIs, FA NAIs, and CoA NAIs.  These are discussed fairly often and 
openly, thought only recently has the HA NAI been "defined" by a draft 
(draft-ietf-mobileip-aaa-nai-05, which BTW we're missing a reference 
for), but the CoA and FA NAIs, though completely analogous and useful, 
are lacking strict definition in our draft.  I've offered to add it 
e.g. in our terminology section, and have also (recently) contacted the 
authors of the above draft to see if they're willing to consider adding 
these, but Pete feels they should be removed from the draft.  My only 
objection here is the draft describes these because it covers all the 
edge cases for how a mobile node could be registered through an FA, and 
all the topologies where such an FA may need to revoke such a binding, 
and removing the cases covered by these NAIs would leave these 
situations unconsidered.

     I've cc:ed Pete directly so there's no risk of my misinterpreting 
his thoughts!

> names would be appropriate too.

     I agree; actually Pete is already thanked in the acknowledgments, 
though we'll be adding his detailed review during last call as well.

> implement this, or need to? If not, kill it. (seems complex if no one

     3GPP2 has stated they require the functionality provided by the 'M' 
bit (at least the 0x01 definition for revoking multiple MNs at one time 
based on their home addresses).  I believe the way we have defined this 
required functionality, namely with a bit to indicate support for 
"multiple revocations" and a mask to indicate the scope of such a 
revocation is the most straight forward way to provide the 
functionality they want, in the most flexible way.

                               Cheers,
                                   Steve

---

From: Kuntal Chowdhury <[email-masked]>
Date: Fri, 04 Apr 2003 11:31:35 -0600

Steven M. Glass wrote:
> by combining it with another draft, 'resource release', wanted by 3GPP2, 
> as well as adding [more] functionality required by the 3GPP2 folks such 
> as e.g. support for revocation of multiple bindings via a single message 
> ('M' bit).
> 

FYI, 3GPP2 decided not to use revocation of multiple bindings with a single 
message (batch revocation). We did not see the need for the complexity involved 
in batch revocation. Therefore I would like to clear the misunderstanding that 
you may have about 3GPP2's requirement.

-Kuntal

---

From: Pete McCann <[email-masked]>
Date: Fri, 4 Apr 2003 11:37:27 -0600

Hi,

Steve has captured my issue with the NAIs pretty well; I actually
don't think FA, CoA, or HA NAI-based revocations are needed by 3GPP2
at this particular point in time (the most important thing is that the
RFC be published ASAP).  I agree that the 'M' bit as applied to ranges
of home addresses is useful and easy to understand.

There is also the question of how to manage changes in the 'M' bit
over time.  My opinion is that the last value of the 'M' bit should
apply agent-wide to all current registrations, whereas Steve thinks it
should be recorded per-binding.

-Pete

---

From: "Subrata Goswami" <[email-masked]>
Date: Fri, 4 Apr 2003 10:26:19 -0800

Here are my comments on the draft.

1. Are there any IPR/patent issues related to this draft ?  
2. A sequence diagram or a general description of Registration
Revocation  process before Section 3 would be beneficial for the reader.
3. In section 3.2 'I' and 'M' bits uses are described in detail without
any hint of what those are. Moving their definitions ahead would help
the reader.

Subrata

---

From: "Steven M. Glass" <[email-masked]>
Date: Fri, 04 Apr 2003 13:45:21 -0500

I actually forgot that last point; sorry Pete.

     To elaborate a bit, the issue is what to do if an agent goes from 
not setting the 'M' bit in its revocation extensions, to setting the 
'M' bit.  In that case there'll be current binding in which the 'M' bit 
was not negotiated, and new binding coming from the same agent (as 
identified by the authentication mechanism) which has the 'M' bit set.  
Does that imply the 'M' bit for the other binding with that agent?  I 
feel it should not, even though I agree it makes things simpler because 
individual bindings won't have to be checked to make sure a non-'M' bit 
registration isn't being included.  If an agent for some reason starts 
to support the feature with the other domain, then as those bindings 
are reregistered they'll eventually all switch to the 'M' bit, but I 
don't feel an agent can presume what the peer's intentions are by 
setting that bit differently for different registrations.

                               Cheers,
                                   Steve