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

[gabriel montenegro <[e-mail]>]

Hi Charlie,

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

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

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

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
> cases) the proposed extension offers benefits for the operation of the 
> 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.

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

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

-- 
Mip4 mailing list: [e-mail]
    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/