[Nfd-dev] LINK spec discussion

[Yingdi Yu]

On Sep 12, 2014, at 9:53 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:

> Dear folks
> 
> In the non-routable web hosting scenario, to achieve the same level of security as IP DNS, we only need redirection and encapsulation LINKs.
> /ndnsim doesn't need /att's permission to host the website under /att/alex-ndnsim. This is similar to IP DNS: to setup an A/AAAA record to that IP address, you don't need IP address owner's permission.
> 
> The procedure of accessing /ndnsim contents is:
> perform a NDNS lookup for /ndnsim, which would return a redirection LINK
> sign[ndnsim](name=/ndnsim, content="redirect=/att/alex-ndnsim")
> replace /ndnsim with /att/alex-ndnsim in all Interests
> to access /ndnsim/index.html, express Interest /att/alex-ndnsim/index.html
I wonder what is the benefit of replacing some part of the non-routable name, instead of simply concatenating the routable-prefix and non-routable name?
> some router near end host or the end host itself or the producer application, must replace /att/alex-ndnsim back to /ndnsim
> to execute signed Interest /ndnsim/action.cgi/[sig], Interest Name across the network is /att/alex-ndnsim/action.cgi/[sig], but the signature is generated based on /ndnsim/action.cgi
It seems that replacement make the router's life harder, because the router cannot do the replacement without knowing the Link object.

> Adding delegation to the mix could prevent an attack in IP DNS.
> In IP DNS, if the owner of a large website points his A record to a smaller website, the large amount of traffic would cause denial of service in the smaller website, although doing so would make the large website itself inaccessible. (This happened once on BAIDU, a top search engine in China; an attacker hijacked BAIDU's Nameserver and pointed A record to a small server).

This attack may happen because DNSSEC is not enable. NDNS records are signed, and resolvers are required to validate that, so the worst case is that no one can do DNS resolution for Baidu, but the small web site should be fine.

> If the owner of (large website) /ndnsim points the NDNS record to another user's namespace such as /verizon/john-victim (small website), it's the same attack as described above.

First, I don't think any descent big website intends to do that. If they really want to attack some small websites, there are a lot of other easy ways to do so instead of sacrificing its own service.

Second, if any attacker want to do that, they have to accumulate a lot of interests, which is not trivial at the first place.

> Storing the delegation record instead of redirection record in NDNS would prevent this attack.

As you mentioned before, if there is not route for those "mis-redirected" interests, the interests will be dropped. Doesn't this prevent the attack?

> A drawback of delegation record is: it promotes content control by ISP.
> In IP DNS, user has the freedom to host any website on the IP address (unless ISP deploys layer-7 filtering).
> If a delegation record is needed, ISP could refuse to sign a delegation record if they don't want user to host a certain website.

Agree. 

> 
> Yours, Junxiao
> 
> On Fri, Sep 12, 2014 at 4:40 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:
> Hi!
> 
> I want continue our discussion about LINK specification (named-data.net/downloads/memos/link.pdf).
> 
> Currently we preliminary defined three elements:
> 
> a) link for redirection:
> 
>     signA("nameA", content: "nameB")
> 
> b) link for delegation
> 
>     signA("nameA", content: signB("nameB", content: "prefixOfNameA"))
> 
> c) "link" for encapsulation
> 
>     sha256("nameB" | "nameA", content: ("delegation or redirection link", data("nameA"))
> 
> 
> The option (b) is the latest addition and I have some reservations about it.  In particular, what exactly this delegation achieves?  What security problem we are solving with it.
> 
> Let me give some example of (b).  I own a "non-routable" namespace /ndnsim and my site is connected to /att and /ucla networks.  So, the (b) option would require:
> 
> - I will have to obtain a "redirection" links from /att and /ucla to /ndnsim (option (a)) = get a permission from /att and /ucla to host /ndnsim site
> 
> - Then I will create a delegation packet(s) that I can put in NDNS to tell others that my site is currently available through /att and /ucla.
> 
> The process looks ok, but the question I have is what significance is in the first permission.  What is the point of me of requesting permission from my provider to host a website?  What I would gain and what provider itself would gain?
> 
> I personally, do not yet see a clear benefit from this process, only that it would complicate the delegation process.  Only me is able to tell others that my site is available at different places, so there is no question about others claiming that my site is available somewhere else.   If I mistakenly put a wrong link, then I myself will be at loss: i wouldn't be able to serve my content and somebody else would receive my interests and could reply to them with some junk.
> 
> If I "maliciously" put somebody else's network as a link, then interests for my data would go there.  But what is the harm?  If nobody replies to them, then routers can start ignoring/pushing back such interests.  If somebody replying, then somebody serves data and from the network point of view nothing bad is happening.
> 
> 
> In short, I want us have a deep discussion on what exactly we are protecting and from whom.  For me, even with only one signature (option a), only the owner of the original namespace (/ndnsim) is able to create a legitimate link to somewhere else.   Additional signature could protect "provider" (destination of the link), but is it really a problem?  Anybody could send any number of interests to that provider even without any link (erroneous or malicious).
> 
> 
> ---
> Alex
> 
> 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140914/556f99f1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140914/556f99f1/attachment.bin>