Re: [rrg] Pumping IRON

["Templin, Fred L" <[e-mail]>]

Hi Wesley,

Thanks for taking a look at this. Please see below for some
follow-up:

> -----Original Message-----
> From: Wesley Eddy [mailto:[e-mail]]
> Sent: Thursday, June 10, 2010 9:13 PM
> To: Templin, Fred L
> Cc: Tony Li; RRG
> Subject: Re: [rrg] Pumping IRON
> 
> Templin, Fred L wrote:
> >
> > As such, I am now initiating a two week open review period
> > within the research group for technical and editorial review.
> > I will also solicit comments from a selected set of expert
> > reviewers to ensure a thorough review. The document version
> > offered for review is here:
> >
> > http://www.ietf.org/id/draft-templin-iron-05.txt
> >
> > To the research group, please post comments to the list as
> > replies to this subject thread by COB on Wednesday, June 23rd.
> >
> 
> 
> Hi Fred, I've looked over the document (and associated ones including
> RANGER, RANGERS, VET, and SEAL); here are some comments I have.
> 
> Summary:
> 
> The document is generally well-written, and can be understood by someone
> within the context of the other referenced documents (though certainly
> not without them).

OK.

> The technical description is basically an overview of the concept and
> how it could function, rather than a prescriptive protocol spec.  I
> think as such it's definitely appropriate to publish through the RG as
> Informational, though I'd suggest that it have a more clear listing of
> some of the open research issues that exist which would be explored in
> taking the concept into a large-scale deployed state.  It would be nice
> to see a bulleted list of such things near the end of the document.

I think I can add something useful in the next document version.
This comment is similar to one I received off-list which suggested
citing the Thomas Narten draft.

> The only technical thing I might have an issue with is the reliance on
> the MVP, and the need to come up with hard numbers to show that this is
> a feasible architectural assumption to work at Internet scale without
> operational issues.  I think those studies would be fine as follow-on
> work and the absence of such should not block publication as an RFC from
> the RG.

What I was thinking here was a model that is sort of along the
lines of how linux kernel distributions are distributed. The
main repository is at kernel.org, but there are numerous mirror
sites to spread the load. (Linux kernel releases are also much
bigger than the largest size I can imagine the MVP database
becoming.) As a follow-on study, I will check to see if there
are statistics associated with this and other similar
distribution systems.
 
> I'm also a little skeptical of the applicability to mobile networks, but
> the claims made here are definitely no more specious than in other
> proposals, so I'm not overly concerned by them ;).
> 
> I would be interested in talking about how IRON compares to an
> architecture where instead of IR(VP)s you have NEMO Home Agents and
> instead of IR(EP)s you have NEMO Mobile Routers (which don't necessarily
> have to be mobile, just speak the protocol).  Assuming you port in the
> use of SEAL for tunnels, there might be a lot of equivalence.  Since the
> EPs and VPs would be routable prefixes in this case, I don't think there
> would be a need for the MVP either, which seems highly desirable to
> dispose of.

Well, the whole reason for having EPs and VPs are to reduce
the sizes of the RIBs and FIBs in all routers. The ability
to delegate EPs to customer sites without requiring that
they be advertised in the global routing table is the
fundamental basis for the IRON scalable PI. Or, perhaps
I misunderstood the comment?

About the NEMO and mobility, let's hold the thought for now
and I will say a few more words about mobility below.
 
> Some comments on particular sections are:
> 
> (1) page 5 - in definitions of different types of IRON routers, the term
> "VP company" is used several times.

Will fix.

> (2) page 5 - in defining different types of IRs, some example diagrams
> might really help.  It's a royal pain to incorporate, so I think this is
> at the authors' discretion, but a couple simple pictures would add a lot
> here, I think.  The scenario in section 6.4 is fantastic for
> illustrating things, but comes too late in the document for readers that
> might get lost up front.

I think I can add a few figures that might help.

> (3) page 6 says:
> """
>     The IRON additionally requires a global mapping database to allow IRs
>     to map EPs/VPs to RLOCs assigned to the interfaces of other IRs.
> """
> This part looks scary at first, and gets a little scarier even when it's
> compared to the way that IANA maintains the list of IPv4 and IPv6
> delegations, and replication across multiple servers is discussed.  I
> think it's probably not as bad of an idea as it seems like at first, but
> I'm really not sure yet.

OK. Again, I am basing my assumptions around the way linux
kernel distributions and similar distribution systems work
today. I will look into this in a follow-on study.

> (4) In section 6.1, and the discussion of beaconing between IR(EP) and
> the IR(VP)s, I wondered how many IR(VP)s we would expect to see in
> operations, where the heuristic of "at least 2-4" was derived from, and
> how frequently it would be advisable to send the beacons at?  Those seem
> like useful details to be understood, though maybe they would be flushed
> out in later studies and through experience to some extent.

I can imagine that for a given VP there may be 10-20 IR(VP)s
worldwide, or perhaps even as many as (say) 50-100. We don't
want each IR(EP) to ping all of the IR(VP)s, so that is why
I was thinking to ping the 2-4 closest ones.

> (5) The discussion of mobility management in 6.5.1 may be a bit
> premature. Whether this is usable or not for mobile systems will depend
> on other aspects of performance like how long the registration of the
> new maping from the EP to RLOC takes with the VP company.  All we have
> to analyze this is that the registration uses "an authenticated short
> transaction protocol", but that might involve handshakes with several
> numbers of steps, and the messages in some steps may be relatively
> large.  The specifics here will matter a lot as to whether IRON is
> viable for mobile networks.

You are right that the IRON "binding update" is coordinated
with all of the IR(VP)s within the VP company instead of with
just a singleton home agent as is the case for MIP. So, there
is certainly a delay for the update to propagate, but I was
thinking there would be some sort of dynamic routing protocol
within the VP company network that could quickly push the
updates to all IR(VP)s.

As to message numbers and sizes for coordinating the binding
update, in past efforts I proposed using cryptographically
signed messages that carry prefix ownership certificates. For
example, the mobile IR(EP) can send a "Router Advertisement"
with its prefix along with a certificate it got from the VP
company. In that way, there is no need for a global PKI, since
each IR(EP) only needs to coordinate its keys with its VP
company and not the entire Internet. Maybe I should bring
this back?  

> (6) The security considerations are a handwave toward RANGER.  I think
> this is not the whole story.  For instance, there are security
> considerations on the means used for customers to update (and establish)
> bindings with their VP companies.  I think the draft implies that the
> exact means could vary depending on the VP company, which is fine, but
> there should be some guidelines or analysis of what kind of bad things
> could happen, and how they might be mitigated or dealt with operationally.

I'll try to add something here. What do you think of the
idea above about having cryptographically signed messages
with certificates issued by the VP company and using the
VP company's private key distribution system instead of
a monolithic global PKI?

Thanks - Fred
[e-mail]
 
> --
> Wes Eddy
> MTI Systems