[Nfd-dev] LINK spec discussion

[Wentao Shang]

On Sun, Sep 14, 2014 at 3:11 PM, Yingdi Yu <yingdi at cs.ucla.edu> wrote:

>
> 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:
>
>    1. perform a NDNS lookup for /ndnsim, which would return a redirection
>    LINK
>    sign[ndnsim](name=/ndnsim, content="redirect=/att/alex-ndnsim")
>    2. 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?
>
>
>    1. 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.
>

A high-level comment without getting into DNS/DNSSEC details:

a link object "A -> B" involves two parties, i.e., A and B. Unless A and B
are actually the same party, you need to have two signatures, one from A
and one from B, to indicate that both parties have agreed on this link
relationship. A single signature (as in the LINK redirect object) is not
enough to prevent such attacks as the one mentioned by Junxiao.

Wentao


>
> 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
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>


-- 
PhD @ IRL, CSD, UCLA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140914/535a6ab8/attachment.html>