Subject: [apps-discuss] Review of draft-lear-lisp-nerd-08

From: S Moonesamy <[email-masked]>
Date: Tue, 10 Apr 2012 14:58:13 -0700

Hi Eliot,

draft-lear-lisp-nerd-08 presents an experimental database and a 
discussion of methods to transport the mapping of EIDs to RLOCs to 
routers in a reliable, scalable, and secure manner.  It does not 
conflict with any work currently being done in the Applications 
Area.  Given that it is an Independent Submission, these comments are optional.

Overall, the draft was an interesting read.  I don't the LISP 
background to perform an adequate review.  I skipped the lengthy 
References section due to lack of time.

In Section 2:

  "Operational functions are split into two components: database updates
    and state exchange between ITR and ETR during a communication."

I suggest expanding ITR and ETR on first use.

In Section 2.1:

   "A NERD is generated by an authority that allocates provider
    independent (PI) addresses (e.g., IANA or an RIR) which are used
    by sites as EIDs."

According to draft-ietf-lisp-06 (Section 3), PI addresses are assigned.

In Section 2.3:

   "Each region runs a database authority.  In this case, provider
    independent address space is allocated to either Regional Internet
    Registries (RIRs) or to affiliates of such organizations of
    network operations guilds (NOGs)."

I am at a loss here.  The draft is talking about PI addresses for a 
region.  Such assignments are generally through RIRs and NIRs and not 
through NOGs.  Shouldn't the paragraph be discussing about 
registration of entries on a regional basis without resorting to an 
apex (see previous paragraph).?

In Section 3:

  "The database name is an ASCII-encoded domain name, as specified in
   [RFC5321]"

Where is that specified in RFC 5321?

  "This is the name that will appear in the Subject field of
   the certificate used to verify the database."

I suggest taking a look at RFC 6125, specifically Section 2.3.

In Section 4.2:

   "This begs the question: how does a router know to retrieve version
    1105450 in our example above?  It cannot.  A redirect must be given
    by the server to that URI when the router attempts to retrieve
    differences from the current version, say, 1105503."

I understand what you mean.  Some readers might consider the above as 
underspecified.

In Section 5.4.1:

   "One possible method of doing this is provided in [RFC4108]"

Section 3 mentions that Cryptographic Message Syntax was not used as 
it is not widely deployed.  Doesn't RFC 4108 require CMS?

In Section 7:

   "Good old NNTP [RFC0977] itself provides two separate mechanisms
   (one push and another pull) to provide a coherent update process."

RFC 3977 obsoletes RFC 977.

In Section 7.1:

    "While the administrative lines may appear to be correct, the
     location of name servers may not be.  If name servers sit within
     PI address space, thus requiring LISP to reach, a circular
     dependency is created."

Wouldn't the service used to resolve the domain names, e.g. for HTTP, 
also sit within PI address space?  The problem (discussed in Section 
8.1) would also apply to any protocol that relies on DNS.

The little gem in the draft is 'The format of the AFI is specified by 
IANA as "Address Family Numbers"'.

Regards,
S. Moonesamy

---

From: Dave Cridland <[email-masked]>
Date: Wed, 11 Apr 2012 10:53:56 +0100

I also had a quick skim.

What struck me was that, given the decision to use object-level  
security over transport-level, there seemed to be portions of  
information left unprotected.

For example, the protocol appears to rely on versioning information  
left unprotected, as well as HTTP-level redirects which also appear  
to be unprotected.

I wondered whether any interesting attack could be mounted by  
presenting older versions of the NERD as newer, meaning that the  
deltas were misinterpreted.

I'd think that the correct thing to do would be to include the  
versioning information within the PKCS#7, and also include expiry  
and/or next-update information, so that participating routers could  
flag up outdated information and alert operators, as well as be  
reasonably aware of when some form of quiet disruption was occuring.

That said, I freely admit that not only is this area not my forté to  
begin with, but I lack experience of LISP at all, so I won't be  
surprised if I'm missing something obvious.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Eliot Lear <[email-masked]>
Date: Thu, 19 Apr 2012 15:12:09 +0200

Hi SM,

Thank you for reviewing draft-lear-lisp-nerd.  Here's an update on this
draft in response to your review:

On 4/10/12 11:58 PM, S Moonesamy wrote:
> conflict with any work currently being done in the Applications Area. 
> Given that it is an Independent Submission, these comments are optional.
>

done.

> According to draft-ietf-lisp-06 (Section 3), PI addresses are assigned.

Correct.

> apex (see previous paragraph).?

This section refers to various approaches that COULD be taken to manage
NERDs.  One such approach is that RIRs manage them.

> Where is that specified in RFC 5321?

I used Section 2.3.5.  However...

> I suggest taking a look at RFC 6125, specifically Section 2.3.

I will modify the text accordingly to use a DNS-ID.

> it is not widely deployed.  Doesn't RFC 4108 require CMS?

This text has been updated to indicate what was used when the experiment
was performed.

> RFC 3977 obsoletes RFC 977.

Ok.

> 8.1) would also apply to any protocol that relies on DNS.

PI doesn't mean routable.

> IANA as "Address Family Numbers"'.

Corrected as well.

Thanks,

Eliot

---

From: S Moonesamy <[email-masked]>
Date: Thu, 19 Apr 2012 10:57:49 -0700

Hi Eliot,
> > According to draft-ietf-lisp-06 (Section 3), PI addresses are assigned.

I should have explained this.  Allocations and assignments are term 
of art in the RIR world.  draft-lear-lisp-nerd-08 uses "allocated".

Ok.

>I used Section 2.3.5.  However...

RFC 5321 contains 5324 lines.  Given that the draft has nothing to do 
with SMTP, it may save the reader some time if the section was mentioned.

>Corrected as well.

The gem I pointed to is that you were correct.  It seems that 
somebody forgot to update the paper trail for 3232 to keep up with the times.

BTW, you could use RFC 5280 as a reference for a X.509 certificate.

Regards,
S. Moonesamy