Subject: Re: [rrg] Some concerns about ILNP//:Re: Recommendation

From: Tony Li <[email-masked]>
Date: Mon, 05 Apr 2010 21:01:13 -0700

Hi Xiaohu,

> If so, wouldn¹t it be used as a way for flooding-attack? For example, one
> or more malicious host could assume an identifier of a target server and
> initiate sessions to a huge mount of hosts, and these hosts will in turn
> return their response packets to the target server. If the returning traffic
> is large, wouldn¹t the target server be flooded?

Seems like there's no amplification, so I don't see how its any different
than a straightforward ping flood.  Same situation as today.
 
> By the way, how could you conclude the connection is a forgery, rather than
> a new legitimate one?

Unless I've lost the context of the thread (a distinct possibility), you
stipulated that it was a forgery.

Regards,
Tony

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 06 Apr 2010 12:15:02 +0800

Hi Tony,

> -----邮件原件-----
> 发件人: Tony Li [mailto:[email-masked]]
> 发送时间: 2010年4月6日 12:01
> 收件人: Xu Xiaohu
> 抄送: [email-masked]
> 主题: Re: Some concerns about ILNP//:Re: [rrg] Recommendation
> 
> 
> Hi Xiaohu,
> 

In today's Internet, uRPF can be deployed to eliminate such attacks (address spoofing).

> stipulated that it was a forgery.

Sorry, let me clarify my thought. Even if the initiator is a forgery (i.e., it impersonates other host), how could the responder distinguish whether it is a forgery or not?

Best wishes,
Xiaohu

---

From: Tony Li <[email-masked]>
Date: Mon, 05 Apr 2010 21:21:38 -0700

> In today's Internet, uRPF can be deployed to eliminate such attacks (address

[Back to where we started?]

We can also do so with IPv6.  And ILNP.

> Sorry, let me clarify my thought. Even if the initiator is a forgery (i.e., it
> impersonates other host), how could the responder distinguish whether it is a
> forgery or not?

A priori, he cannot, just as is the situation today.

Tony

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 06 Apr 2010 16:05:45 +0800

> > Sorry, let me clarify my thought. Even if the initiator is a forgery
(i.e.,
> it
> > impersonates other host), how could the responder distinguish whether it
is
> a

As such, some mechanisms described in Section 12.2 "Forged Identifier
Attacks" of draft-rja-ilnp-intro-03 seem problematic. Correct?

Best wishes,
Xiaohu

---

From: Tony Li <[email-masked]>
Date: Tue, 06 Apr 2010 08:04:20 -0700

> Attacks" of draft-rja-ilnp-intro-03 seem problematic. Correct?

Not at all.  In fact, that is where all of the answers to your concerns are
discussed.

Tony

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 07 Apr 2010 08:45:57 +0800

Hi Tony,

> 发送时间: 2010年4月6日 23:04
   
 The following text is quoted from the Section 12.2:
   "Second, the receiving node does not blindly accept any packet
   with the proper Source Identifier and proper Destination
   Identifier as an authentic packet.  Instead, each node operating
   the I/L-split mode maintains a session cache for each of its
   correspondents, as described above.  This cache contains two
   unidirectional nonce values (one used in control messages sent by
   this node, a different one used to authenticate messages from the
   other node).  The cache also contains the currently valid set of
   Locators and set of Identifiers for each correspondent node.  If
   a received packet contains valid Identifier values and a valid
   Destination Locator, but contains a Source Locator value that is
   not present in the session cache, the packet is dropped without
   further processing as an invalid packet, unless the packet also
   contains a Nonce Destination Option with the correct value used
   for packets from the node with that Source Identifier to this
   node.  This prevents an off-path attacker from stealing an
   existing session."

This is the previous discussion content:

> >>>>> CONCERN #2: Host ID Global Uniqueness Assurance
> >>> Again, absolutely nothing will happen.  Identifiers are not global,
they
> are
> >> only unique _within_ a locator.  Thus, if your cache contains:
> >>
> >>     (Locator A, Identifier I, Nonce N, Destination D)
> >>     (Locator B, Identifier I, Nonce K, Destination D)
> >>
> >> And you now receive a packet with
> >>
> >>     (Locator C, Identifier I, Nonce L, Destination D)
> >>
> >> Then the receiver drops it per the above rule.  It's clearly a forgery.
> >
> > Why do you clearly believe the packet with (Locator C, Identifier I,
Nonce
> > L, Destination D) is a forgery? ILNP doesn't require the identifier to
be
> > globally unique. In other words, it is absolutely possible and
legitimate
> > that two hosts having the same identifier communicate with a third party
at
> > the same time.
> 
> 
> You're correct.  I should have said that the packet does NOT match any
> current connection and thus appears to be an independent entity.
> 
> 
> > According to your above logic, if a malicious host impersonates the
> > legitimate identifier owner and establishes a session with a given
server
> in
> > advance, does that mean the legitimate identifier owner will not be able
to
> > access that server later?
> 
> 
> No, since a new connection was established.

Are the above two arguments in accordance with each other?

Best wishes,
Xiaohu

---

From: Tony Li <[email-masked]>
Date: Tue, 06 Apr 2010 18:23:08 -0700

Hi Xiaohu,

> Are the above two arguments in accordance with each other?

Ah, I finally see what you're getting at.  In particular, this comment

>> current connection and thus appears to be an independent entity.

... Conflicts with 

>    "If
>    node."

In particular, simply discarding it may be incorrect, as there may be an
Identifier collision from another, unrelated source domain.  This can be
entirely legitimate.  For example, it could be a SYN for a new connection.

Let's propose alternate replacement text:

    If a packet is received, its Source Locator, Source Identifier,
    Destination Locator, Destination Identifier and Nonce Destination Option
    value are compared to the values found in the cache.  If these values do
    not match a correspondent found in the cache, then the packet is deemed
    to have come from a new correspondent.

Does that clarify the issue?  Ran, does this work?

Regards,
Tony