Subject: [Mip4] review: draft-ietf-mip4-faerr-01.txt

From: gabriel montenegro <[email-masked]>
Date: Fri, 9 Sep 2005 10:30:53 -0700 (PDT)

I reviewed this draft and had some comments interspersed below. 

...
> Abstract
> 
>    This document specifies a new extension for use by Foreign Agents
>    operating Mobile IP for IPv4.  The new extension option allows a
>    foreign agent to supply an error code without disturbing the data
>    supplied by the Home Agent within the Registration Reply message.
>    In this way, the mobile node can verify that the Registration
>    Reply message was generated by the Home Agent even in cases where
>    the foreign agent is required by protocol to insert new status
>    information into the Registration Reply message.

This abstract is the same as the introduction. Please edit both according to the usual
editorial guidelines as to what an abstract and an intro should contain. They should not
remain the same.

> 1. Introduction
> 
>    This document specifies a new non-skippable extension for use
>    by Foreign Agents operating Mobile IP for IPv4 [2].  The new
>    extension option allows a foreign agent to supply an error code
>    without disturbing the data supplied by the Home Agent within the
>    Registration Reply message.  In this way, the mobile node can
verify
>    that the Registration Reply message was generated by the Home Agent
>    even in cases where the foreign agent is required by protocol to
>    insert new status information into the Registration Reply message.
...

> 5. Mobile Node Considerations
> 
>    If a mobile node receives a successful Registration Reply (status
>    code 0 or 1), with a FA Error extension indicating that the foreign
>    agent is not honoring Registration Reply, the mobile node SHOULD

s/honoring Registration/honoring said Registration/

> 6. IANA Considerations
...
>    document.  Future allocations from this number space require IETF
>    consensus.

Not sure why IETF consensus. As per http://www.iana.org/numbers.html#M,
MIPv4 assignments are done via Expert Review, whereas MIPv6 are done via Standards
Action. It's bad enough that these are not in sync, but adding yet another criterion
("IETF consensus") would mix things even more.
Unless there's a strong reason not to, I suggest remaining in sync with MIPv4 ("Expert
Review").

...

> 
> 
> 7. Security Considerations
> 
...
>    by destroying the ability of the mobile device to authenticated the

s/authenticated/authenticate/  or perhaps even better just "verify"

>    Mobile-Home Authentication Extension data.

> 
>    In many typical cases, the mobile node will not have a security
>    association with the foreign agent that has sent the extension.
>    Thus, the mobile node will be unable to ascertain that the foreign
> 

...

> 7. Security Considerations
> 
>    The extension in this document improves the security features
>    of Mobile IPv4 by allowing the mobile node to be assured of the
>    authenticity of the information supplied within a Registration
>    Request.  Previously, whenever the foreign agent was required to
>    provide status information to the mobile node, it could only do so
>    by destroying the ability of the mobile device to authenticated the
>    Mobile-Home Authentication Extension data.

This *sounds* good, but the next paragraph contradicts it. As I think about
this a bit more, one could argue that the opposite effect is true. Suppose
the FA has no security association with the MN (the so-called "typical case"
below). Before this extension, upon receiving a Reg Reply from the HA, an FA could 
do 2 things:

1. relay the Reg Reply as-is from the HA
   
   The MN has assurance of the validity of the Reg Reply

2. obliterate it and send its own Reg Reply (replacing the HA's code in the
   Reg Reply effectively means the FA will regenerate and send its own)

   The MN has no assurance of the validity of the Reg Reply

Now, in addition to the above:

3. the FA can add its own code which cannot be ignored

  The MN has no assurance of the validity of the (overall) Reg Reply (in the "typical"
case),
  cuz even if the HA portion checks out fine, the FA portion cannot be ignored, so the MN
is
  presumably forced to ignore validated information if the FA adds its own non-validated
information.

Whereas before the MN had the ability to validate information in 1 out of 2 cases, the
situation
is now worse cuz it can only do so in 1 out of 3 cases. If this extension is allowed
without
any security association (the "typical" case), I'm afraid it worsens matters.
 
>    In many typical cases, the mobile node will not have a security
>    association with the foreign agent that has sent the extension.
>    Thus, the mobile node will be unable to ascertain that the foreign
>    agent sending the extended Registration Reply message is the same
>    foreign agent that earlier received the associated Registration
>    Request from the mobile node.  

This basic issue negates the purported benefits of the extension. Should such "typical
cases" not be encouraged? Supposedly, this draft was created primarily for use by
3012bis. Such usage does not fall under the "typical" case alluded to above, because it
requires either an MN-FA Authentication Extension or an MN-AAA Authentication Extension.
Whereas it is not obvious how the MN-AAA authentication extension would provide
any assurance to the MN about the FA (well, perhaps the AAA infrastructure could "vouch"
for the
FA to reassure the MN), it seems prudent to impose some security on the use of this 
extension (as 3012bis requires).

>    Because of this, a malicious foreign
>    agent could cause a mobile node to operate as if the registration
had
>    failed, when in fact its home agent and a correctly operating
foreign
>    agent had both accepted the mobile node's Registration Request.  In
>    order to reduce the vulnerability to such maliciously transmitted
>    Registration Reply messages with the unauthenticated extension, the
>    mobile node MAY delay processing of such Registration Reply
messages
>    for a short while in order to determine whether another authentic
>    Registration Reply might be received fromm the true foreign agent.

s/fromm/from/

Well, you don't know if it is the "true" foreign agent or yet another bogus reply...
Again, it seems prudent to require some security association when using this extension
(MUST or SHOULD, unlike the current text 
in which a typical case has no security).

-gabriel

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 18 Sep 2005 19:42:42 +0300

Hello Gabriel,

>>   insert new status information into the Registration Reply message.
A lot of documents are like that.  It would be nice if you could
provide a little more insight into the kind of revision you believe
would be proper.  Or, even better, please send text either for
a new abstract or some part of the introduction.

Do you have a reference I can consult that explains the usual
editorial guidelines?  Is your reference suited for protocol
documents?

>s/honoring Registration/honoring said Registration/
Done!

>Unless there's a strong reason not to, I suggest remaining in sync with MIPv4 ("Expert
Done, along with a motivational sentence as you suggest.

>s/authenticated/authenticate/  or perhaps even better just "verify"
Done.

>any security association (the "typical" case), I'm afraid it worsens matters.
You can't argue this from such a case analysis, because the cases do not 
at all
have equal weights.  For one thing, in most cases there aren't any 
malicious FAs
in the neighborhood.  If you don't believe this, then we may not have 
very much
common ground for discussion!  For all such cases (the preponderance of all
cases) the proposed extension offers benefits for the operation of the 
proper
(non-malicious) FAs.

But please look at my reply to Kent regarding the case of malicious FAs.
As noted, I really do not think we have a problem that merits drastic 
measure
to solve.

>>   Registration Reply might be received fromm the true foreign agent.
Done!

>in which a typical case has no security).
Well, I don't agree with this.  Of course we can recommend the use
of security measures, when available, to combat the threat.  But to 
proscribe
the use of this extension except when additional security measures are
available, is not very constructive and damages the more common case.

Regards,
Charlie P.

---

From: gabriel montenegro <[email-masked]>
Date: Sun, 18 Sep 2005 23:34:34 -0700 (PDT)

Hi Charlie,

...
...
> editorial guidelines?  Is your reference suited for protocol

I'm sure you can find proper guides on technical writing. Even in the absence of those,
the IETF does go out of its way to recommend some guidelines. If you go to the main
ietf page, you can access the internet-draft's page:

http://www.ietf.org/ID.html

from which you're referred to documents with some advice on what abstracts and 
intros should have. For example:

The I-D Checklist:
http://psg.com/~bwijnen/ID-Checklist.html

Guidelines to Authors of Internet-Drafts
http://www.ietf.org/ietf/1id-guidelines.html

Instructions to Request for Comments (RFC) Authors
http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt

> common ground for discussion! 

If you believe security should be built on what the common case known today is,
then we can arrive at this same conclusion. :)  These are not probabilistic adversaries
(like nature), these are determined adversaries.

> For all such cases (the preponderance of all

Agree with this. It also offers benefits for the operation of non-proper (malicious or
false) FAs.

It's not the FAs I'm worried about. I'm just not sure how well the MNs fare in all of
this.
And this may not make things terribly worse for them, but I don't agree that it makes
them
any better.

> As noted, I really do not think we have a problem that merits drastic 

Not sure if that applies to what I was suggesting, as I consider it non-drastic:
acknowledge that from the point of view of the MN the benefits it may gain depend
on its having some trust in the FA. Calling the "no MN-FA Auth Ext" case "typical"
may be accurate, but it's somewhat misleading in that quite commonly there is
some trust in place. For exampole, if the FA is the PDSN there is some trust in 
place cuz of the nature of that link technology. Even in the commonly deployed
cases, there may be some trust in place. Recognizing and recommending that may
not be a drastic measure.

-gabriel

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 19 Sep 2005 10:39:25 +0300

Hello Gabriel,

Let's try to get closure on these things ASAP.

gabriel montenegro wrote:

>I'm sure you can find proper guides on technical writing.
>
Here's what the IETF page says, following your links:

> Composing a useful Abstract is a non-trivial writing task. Often, a 
> satisfactory abstract can be constructed in part from material from 
> the Introduction section, but a good abstract will be shorter, less 
> detailed, and broader in scope than the Introduction. Simply copying 
> and pasting the first few paragraphs of the Introduction is tempting, 
> but it generally results in an Abstract that is both incomplete and 
> redundant.

I can fill out the Introduction some more, but my belief is that it's 
inappropriate
to require a long Introduction for a document that would be quite short 
except
for all the boilerplate sections.  It would be nicer if you would say 
what you
wanted so I wouldn't have to iterate and guess.  I'm not writing a book or
even a book chapter, and "pro-forma" recommendations aren't constructive
in my opinion, given this perspective.  My temptation would be to make the
abstract even shorter, which would fulfill the "pro-forma" request, but you
might take that as uncooperative so I definietly will not do that unless you
agree it's the correct approach.

>If you believe security should be built on what the common case known today is, then we can arrive at this same conclusion. :)  These are not 
>probabilistic adversaries (like nature), these are determined adversaries.
>  
>
I believe that security should be built to protect the protocol against
dangerous vulnerabilities.  I do not intend to throw out the welcome mat
to any determined adversaries.  I hope you will be able to see my remarks
in this context.

>>proper (non-malicious) FAs.
>>    
>>
>
>Agree with this. It also offers benefits for the operation of non-proper (malicious or false) FAs.
>
>It's not the FAs I'm worried about. I'm just not sure how well the MNs fare in all of this.
>And this may not make things terribly worse for them, but I don't agree that it makes them any better.
>  
>
It makes things better for the mobile nodes because:
(i) in the usual case (no adversaries) a better determination can be made
    about whether the home agent saw the registration, and
(ii) in the unusual case (adversary present in neighborhood), the damage is
   not appreciably worse.
So we can say that the extension usually makes things better, and almost
never makes them worse.

>acknowledge that from the point of view of the MN the benefits it may gain depend on its having some trust in the FA.
>
I do not agree with this -- see above.  From the point of view of the MN,
benefits are "usually" gained except in the presence of a knowledgeable
adversary.

> Calling the "no MN-FA Auth Ext" case "typical"
>some trust in place.
O.K.  I would like to find a better word than "typical".  How about the 
"common" case
instead of the "typical" case?  Or, maybe, the "more common" case?

> For exampole, if the FA is the PDSN there is some trust in 
I have no problem with this.  I thought I was reading some recommendation
to MANDATE the use of a security association with this extension.  That
would be drastic, and wrong in my opinion.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 19 Sep 2005 15:47:40 +0300

Hello folks,

I made a new document.  It might not be "done" yet until
the current issues are agreed to have been resolved, but
anyway it's available if you want to have a look, at the
following URL:
    http://people.nokia.net/charliep/txt/mobilefaerr/faerr.txt

Regards,
Charlie P.

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 19 Sep 2005 08:56:15 -0700 (PDT)

Hi Charlie,

...
> agree it's the correct approach.

The point I wanted to make was that this seemed to me like a case of "copy and paste"
and that some reflection might be in order. Your suggestion to make the abstract more
succint is fine, I think.

> >If you believe security should be built on what the common case known today is, then
> we can arrive at this same conclusion. :)  These are not 
> them any better.

Let's agree to disagree.

> instead of the "typical" case?  Or, maybe, the "more common" case?

The word is not as important as how it is qualified. Seems like we have some
agreement after this next paragraph...

> would be drastic, and wrong in my opinion.

ok.

-gabriel