Subject: Re: [rrg] Issue #1 from Heiner Hummel

From: [email-masked]
Date: Thu, 17 Jun 2010 06:21:15 EDT

I always thought you would come up with some hierarchical location value  
space when ILNP will be processed.
Now I realize, you will (re)use IPv6-prefixes (restricted to 64  bits) that 
are uniquely assigned to so-called point of attachments of any  particular 
ISP's subnetwork, right?
BTW, why prefix ? why not address of precisely 64 bits?
Hosts communicate via DNS their point-of-attachments' prefix (whereby  
multiple hosts may share the same such prefix).
All these point-of-attachment routers communicate to the outside that they  
have reachability to such a prefix. This is the same as what a BGP router 
is  doing.
I.e. this doesn't reduce the number of prefixes. 
By assuming that today's network administrator do a good job while trying  
to come up with reasonable prefixes, I cannot see what is the ILNP's 
reduction  of prefixes to be spread all over.
 
A different syntactical point: 
You camouflage your design by using the term locator although you do not  
intend that to be a denotion of location.
Granted, you just continue with this bad habit which indeed comes  from the 
"loc/id"-split discussion, where also at no point in time "loc"
expressed anything like location.
You hereby play foul to those who want location-based routing, because you  
educate people to understand something else than a locator ought to mean.
And you pave the ground such that people would get confused when someone  
uses the word locator in its true meaning.
I am convinced that you would say NO if a straw poll statement states: "A  
node's locator" denotes the location of that node".
 
You provide (via DNS) a different way to learn about the mentioned prefix,  
but that's it. I accredit to you that you won't worsen the stretch-of-path  
behavior.
You still do the same, only slightly changed. But you also won't improve  
routing capabilities (extending to numer of alternative detours, 
selecting the right alternative based on actual traffic sizes).
 
Heiner

 

In einer eMail vom 16.06.2010 20:00:26 Westeuropäische Sommerzeit schreibt  
[email-masked]:

Earlier,  Heiner Hummel wrote:
> draft-rja-ilnp-intro-03, Section 1, Page 4, says  in part:
> % The high-order 64-bits of the IPv6 address become the  Locator.
> % The Locator indicates the subnetwork point of attachment  for
> % a node.  In essence, the Locator names a subnetwork.   Locators
> % are also known as Routing Prefixes.
> 
> Yes,  this was all that I had found before asking my question.
> Now Tony  tells me, it is simply the IPv6 address space.

Tony's response is fine,  if slightly imprecise, but apparently 
his comment was made with respect to  ILNPv6 rather than 
in general.  

(I mean "imprecise" above in  that an IPv6 Address is a
128-bit object that includes a 64-bit routing  prefix;
meanwhile an ILNPv6 Locator is a 64-bit object that
is a 64-bit  routing prefix).

For ILNPv4, Locators are formed from IPv4 routing  prefixes.

While the engineering of ILNPv4 and ILNPv6 are  necessarily
different (in order to be backwards compatible with IPv4
and  IPv6 respectively), the ILNP architecture is identical.

> What is  here any better/different from LISP-2 ?
> 
> I am confused. This  sounds like Karl Valentin.
> Though the left spotlight (IPv4) on a stage  was down,
> he tried to repair the right one (IPv6).

Opinions  vary on whether ILNPv6 will be widely deployed.
Opinions vary on whether  ILNPv4 will be widely deployed.

ILNP is an architecture, that can be  applied to a range
of networking protocols.  As an example, one could  also
apply the ILNP architecture to OSI CLNP.

I've taken an action  to more clearly describe how ILNP 
could be applied to IPv4 in my  in-process editing of 
draft-rja-ilnp-intro.  I hope that will clarify  any  
confusion.

Yours,

Ran

_______________________________________________
rrg  mailing  list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 17 Jun 2010 08:48:01 -0400

On 17  Jun 2010, at 06:21 , [email-masked] wrote:
> I always thought you would come up with some
> hierarchical location value space when ILNP
> will be processed.

IP routing prefixes already are heirarchical, 
at least since CIDR was widely deployed 
(which almost 20 years ago at this point).

For IPv6 specifically, please see 
[RFC-4291, Section 2.5] and elsewhere.

So I'm confused by your statement above.

> Now I realize, you will (re)use IPv6-prefixes (restricted to 64  bits)

IPv6 routing prefixes are already restricted to 64-bits,
with the low-order 64-bits being an *interface* identifier.
[RFC-4291, Section 2.5.1 & elsewhere]

> that are uniquely assigned to so-called point of attachments
> of any particular ISP's subnetwork, right?

They might or might not be "any particular ISP's subnetwork",
depending a great deal on how one defines "ISP".

Purely as an example, the US Defense Information Systems
Agency (DISA) <http://www.disa.mil> has direct allocations
of both IPv4 and IPv6 address blocks.  Different people
have different opinions about whether DISA is an "ISP".

On the one hand, DISA is a government agency, and 
its users (i.e. other US DoD activities) are required 
to use DISA for IP connectivity.  So some view DISA 
as analogous to the IT group for a very large enterprise.   

On the other hand, DISA bills other DoD organisations 
for their IP connectivity, and it provides transit services 
for its users, so other folks view DISA as an ISP.

> BTW, why prefix ? why not address of precisely 64 bits?

Hmm.  ILNP does not have addresses at all.  

An "address" is an object that has mixed ("overloaded") 
semantics.  An "address" is sometimes used for location 
(e.g. with IP routing) and other times is used for identity 
(e.g. in the TCP or UDP pseudo-header checksum).  

The entire concept of an "address" is deprecated with ILNP, 
in favour of separate Locator and Identifier objects, 
each having distinct and very crisp semantics.

> Hosts communicate via DNS their point-of-attachments' prefix
> (whereby  multiple hosts may share the same such prefix).

I find the sentence above confusing.  

I think the above might be trying to say that an ILNP node 
advertises its Locator value(s) via the DNS, which is 
precisely true, but incomplete.  An ILNP node will also 
use the ICMP Locator Update message to advertise changes 
to its working set of Locators to existing correspondents,
for example.

> All these point-of-attachment routers communicate
> to the outside that they have reachability to such a prefix.
> This is the same as what a BGP router is doing.

Ah.  

I am not sure, but I think the question is how ILNP enables 
the number of DFZ RIB/FIB prefixes to be reduced.  The
shortest answer is by aggregation of routing prefixes.

Today it is nearly impossible to aggregate much, simply
because upper-layer protocols, notably TCP and UDP, 
use the IP address -- including the upstream routing
prefix -- for identity.  ILNP eliminates this semantic
overloading inherent in today's IP address, permitting
high-availability multi-homing to different upstream
providers while also permitting significantly more
prefix aggregation than is possible today.

This was answered recently by several other folks,
notably Chris Morrow, who has extensive ISP experience.
I'll point to some of his previous notes here:

<http://www.ietf.org/mail-archive/web/rrg/current/msg06762.html>

<http://www.ietf.org/mail-archive/web/rrg/current/msg06783.html>

<http://www.ietf.org/mail-archive/web/rrg/current/msg06824.html>

<http://www.ietf.org/mail-archive/web/rrg/current/msg06754.html>

Several other folks, including tli, fred, and Joel Halpern
(all of whom have EXTENSIVE experience with Internet routing)
have also addressed this issue in the past.  I don't want
to cite every prior note to the RRG list explaining this,
but as another example, this note from fred is quite clear:

<http://www.ietf.org/mail-archive/web/rrg/current/msg06755.html>

> reduction  of prefixes to be spread all over.

I am sure I do not understand what the above is trying to say.

> intend that to be a denotion of location.

Incorrect on two counts.

1) I am killing myself trying to be clear, which is rather
   the opposite of "camoflage".  

   (One might argue that your note indicates I am not fully
    succeeding in being as clear as I'd like, but I'm 
    certainly not 'camoflaging' anything.)

2) The Locator absolutely does denote location, and never identity.

> expressed anything like location.

The ILNP Locator precisely specifies a subnetwork,
so it is precisely specifying a location.

> educate people to understand something else than a locator ought to mean.

Au contraire.  

My usage is both quite clear, and is also the long-standing 
usage in the Internet community.
  
JNC has observed on this list in the past that the general 
usage of "locator", which is the same as with ILNP, goes back 
over 10 years now -- including to published RFCs from some
years back.  JNC has written several notes about this.

Purely as an example, consider this note from him:
  <http://www.ietf.org/mail-archive/web/rrg/current/msg06842.html>

> uses the word locator in its true meaning.

I have no idea what that is trying to say.

I will note that my usage is entirely consistent with 
the common usage within the Internet community.

> node's locator" denotes the location of that node".

Your crystal ball appears to be broken.

[Aside:  The Terminology Straw Poll (interim) results are public,
so folks can see my views about the terminology statements
that are on the table for the poll.]

> selecting the right alternative based on actual traffic sizes).

I don't understand those words either, terribly sorry.

Yours,

Ran

---

From: Paul Jakma <[email-masked]>
Date: Thu, 17 Jun 2010 16:19:12 +0100 (BST)

On Thu, 17 Jun 2010, [email-masked] wrote:

> You hereby play foul to those who want location-based routing, 
> because you educate people to understand something else than a 
> locator ought to mean. And you pave the ground such that people 
> would get confused when someone uses the word locator in its true 
> meaning.

I don't think ILNP changes the notion of "locator" at all. The 
"address" continues to have a topological component as far as routing 
is concerned.

ILNP provides a clear line as to what part of the address may be 
considered for topological routing. Changes beyond that are just 
host-side, to decouple ULPs from the locator portion - that's 
intrinsically a good thing, methinks.

Ratifying an L/I split, and that ULPs should not bind the I to any L 
for ILNP seems intrinsically a good thing. It would not prejudice any 
routing work, I think.

The ony thing that's unclear to me is whether the ILNPv6 space should 
be a new address family or a defined subset of the IPv6 number space. 
Indeed, it's unclear to me what the ILNP authors think on this topic. 
It perhaps would be nice to see worked examples - the papers seem not 
to have them.

I ask this because it would be good to strive for maximum 
compatibility as much as possible. E.g. it'd be nice if ILNPv6 
sockets would have IPv6 addresses and could be used to accept IPv6 
connections, and connect out to legacy IPv6. There are a lot of 
details here that don't yet seem to be fully described.

Also, it's perhaps unfortunate that the links on the main ILNP to 
some of the more detailed papers go to academic journal paywalls. It 
would be good if there were direct links to the PDFs concerned.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
God requireth not a uniformity of religion.
- Roger Williams

---

From: Tony Li <[email-masked]>
Date: Thu, 17 Jun 2010 09:20:34 -0700

> The ony thing that's unclear to me is whether the ILNPv6 space should be a new address family or a defined subset of the IPv6 number space. Indeed, it's unclear to me what the ILNP authors think on this topic. It perhaps would be nice to see worked examples - the papers seem not to have them.

In order for ILNP to be backward compatible and interoperable with legacy IPv6 hosts, it must use the exact same namespace.

Tony

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 17 Jun 2010 13:11:05 -0400

On 17  Jun 2010, at 12:20 , Tony Li wrote:
>> The only thing that's unclear to me is whether the ILNPv6
>> space should be a new address family or a defined subset
>> of the IPv6 number space. Indeed, it's unclear to me what
>> the ILNP authors think on this topic.  It perhaps would be
>> nice to see worked examples - the papers seem not to have them.
> 
> In order for ILNP to be backward compatible and interoperable
> with legacy IPv6 hosts, it must use the exact same namespace.

(Just to be clear)

Tony is quite correct, both about the reasons and
also about what ILNPv6 does.

An ILNPv6 Locator does not use "a defined subset of the IPv6 
number space", nor a separate number space, but instead an 
ILNPv6 Locator uses the entire IPv6 routing number space.

Similarly, an ILNPv4 Locator uses the entire 
IPv4 routing number space.

Backwards-compatibility is a major design & engineering 
objective (and also a provided property) of ILNP -- 
both for ILNPv4 & ILNPv6.

(To the authors of the papers, this was obvious.
We're sorry if that wasn't as obvious to others.)

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 17 Jun 2010 13:28:50 -0400

On 17  Jun 2010, at 11:19 , Paul Jakma wrote:
> I don't think ILNP changes the notion of "locator" at all.
> The "address" continues to have a topological component
> as far as routing is concerned.

Disagree.  

ILNP does NOT have the concept of an 'address'.  

Instead, ILNP splits the atom into 2 separate objects, 
one for identity only and the other for location only.

With ILNP, routing uses only Locators, never Identifiers.

> ILNP provides a clear line as to what part of the address
> may be considered for topological routing. Changes beyond
> that are just host-side, to decouple ULPs from the locator
> portion - that's intrinsically a good thing, methinks.
> 
> Ratifying an L/I split, and that ULPs should not bind the
> I to any L for ILNP seems intrinsically a good thing.
> It would not prejudice any routing work, I think.

Thanks very much.  

> compatibility as much as possible. E.g. it'd be nice if
> ILNPv6 sockets would have IPv6 addresses and could be used
> to accept IPv6 connections, and connect out to legacy IPv6.
> There are a lot of details here that don't yet seem to be
> fully described.

This is well covered already.  For example, please
go read draft-rja-ilnp-intro-03.txt, Section 8.

> Also, it's perhaps unfortunate that the links on the main
> ILNP to some of the more detailed papers go to academic journal
> paywalls. It would be good if there were direct links
> to the PDFs concerned.

I just double-checked on the project web site.
For the benefit of others that web site is at:
	<http://ilnp.cs.st-andrews.ac.uk>

With 1 exception, all papers there already *are* direct 
links to local copies of the PDFs concerned.

The links throughout the project page are organised with 
the most recent publication date at the top of each section, 
which is common practice for academic web sites of this sort.

(The project web site is at:   http://ilnp.cs.st-andrews.ac.uk)

So the plural quoted above ("links") seems to have been a typo.

As discussed before on this list, that one link (to Springer-Verlag)
is for a journal paper that the authors' can NOT put out directly,
due to legal (e.g. copyright) restrictions from the journal publisher.

Yours,

Ran Atkinson

---

From: Paul Jakma <[email-masked]>
Date: Thu, 17 Jun 2010 20:03:26 +0100 (BST)

On Thu, 17 Jun 2010, Tony Li wrote:

> In order for ILNP to be backward compatible and interoperable with 
> legacy IPv6 hosts, it must use the exact same namespace.

The exact same, or a subset? Anyway..

I'm curious how backward compatibility is to work for applications 
accepting connections on ILNP-capable hosts. In particular, how to 
know whether to calculate the ULP checksum over the full L+I or just 
the ILNP style I?

Looking further at the docs, it seems this relies on the Nonce Option 
having stateful semantics to indicate "this remote IP knows ILNP". 
How will this scale exactly? E.g. imagine servers communicating with 
large numbers of clients.

What happens when IPs are re-used for hosts? Can you rely on Locator 
Updates reaching those other hosts that are caching things.

It'd be interesting if someone did a comparison between Shim6 and 
ILNP, as Shim6 spent a fair bit of effort on looking at issues 
involving maintaining the locator<->ULP ID binding.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
A lie is an abomination unto the Lord and a very present help in time of
trouble.
 		-- Adlai Stevenson

---

From: Paul Jakma <[email-masked]>
Date: Thu, 17 Jun 2010 20:10:37 +0100 (BST)

> ILNP does NOT have the concept of an 'address'.

Sure, ILNP does not. As per the docs though, ILNP is an end-host 
technology. Intermediate routers continue to treat the packets as IP, 
and in that context it is not inappropriate to call that field an 
address.

I could be sarcastic and say that should be obvious, but I'm not sure 
sarcasm helps greatly in promoting productive discourse ;).

> So the plural quoted above ("links") seems to have been a typo.

Ha, my bad. However, the most recent paper there is the paywalled 
link. FWIW, this doesn't affect me, but it may affect others.

> due to legal (e.g. copyright) restrictions from the journal publisher.

Sounds like a journal to avoid so. ;)

thanks,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
"No matter where you go, there you are..."
-- Buckaroo Banzai

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 17 Jun 2010 15:36:31 -0400

On 17  Jun 2010, at 15:03 , Paul Jakma wrote:
> I'm curious how backward compatibility is to work for applications accepting connections on ILNP-capable hosts. In particular, how to know whether to calculate the ULP checksum over the full L+I or just the ILNP style I?

This is described in detail in draft-rja-ilnp-intro.

> Looking further at the docs, it seems this relies on the Nonce Option having stateful semantics to indicate "this remote IP knows ILNP". How will this scale exactly? E.g. imagine servers communicating with large numbers of clients.

Scaling should be just fine.

Existing TCP/IPv4 implementations for web servers already keep 
a significant amount of session state for each TCP session.
This is known to scale adequately for very large numbers of
TCP sessions in several major operating systems (for example,
in Solaris and FreeBSD).

The additional ILNP session state required is relatively
small, and scales per-correspondent-node, rather than
per-TCP-session.

A typical web browser opens N parallel TCP sessions to the same 
server node.  So the ILNP session state should actually scale 
a bit better than TCP session state.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 17 Jun 2010 15:42:11 -0400

[  Folks, PLEASE limit oneself to 1 issue per thread.  
   If one has multiple issues, please put them in separate 
   email messages with distinct Subject: lines. 
   I'm trying to separate things as I go along,
   but it is simpler for everyone on the list 
   if they begin life as separate email threads. :-]

On 17  Jun 2010, at 15:03 , Paul Jakma wrote:
> What happens when IPs are re-used for hosts? Can you rely on Locator Updates reaching those other hosts that are caching things.

I don't understand the question.

> It'd be interesting if someone did a comparison
> between Shim6 and ILNP, as Shim6 spent a fair bit
> of effort on looking at issues involving maintaining
> the locator<->ULP ID binding.

Sorry, I have extremely little time available for ILNP stuff.
So I don't have any time to undertake that.

At a very high level, it is possible that the engineering
of SHIM6 might have some similarities to the engineering 
of ILNP for at least some OS environments.  

However, the SHIM6 architecture is very different from ILNP.  
For openers, SHIM6 increases the semantic overloading of the 
IPv6 address, while ILNP eliminates that semantic overloading.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 17 Jun 2010 15:53:49 -0400

On 17  Jun 2010, at 15:10 , Paul Jakma wrote:
> As per the docs though, ILNP is an end-host technology.

I would not agree with that statement.

Instead, I'd say that ILNP does not *require* 
router changes.  Avoiding a requirement to
change routers enables cooperating nodes
to incrementally upgrade, which seems very important.

However, it is definitely also true that ILNP enables 
implementation/deployment of new router features that 
aren't practical today with IP.

For example, Locator Rewriting by site border routers 
is clearly not an end-host technology.  ILNP's approach
to Locator Rewriting is different from IP NAT in several
ways, for example in that one need not be concerned with 
recalculating TCP/UDP checksums or deploying complex IPsec 
NAT-tunnelling schemes.

The locator rewriting capability is optional to implement, 
and optional to deploy, so it doesn't gate ILNP,
but the feature itself is clearly documented.  Among other places, 
it is described in some detail in the MILCOM 2009 paper
on 'Site-controlled Multi-Homing & Traffic Engineering'.

> Intermediate routers continue to treat the packets as IP, ...

Not necessarily true, please see one counter-example above.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 17 Jun 2010 15:55:08 -0400

> The exact same, or a subset? Anyway..

Exactly the same.

Ran

---

From: Paul Jakma <[email-masked]>
Date: Thu, 17 Jun 2010 22:21:00 +0100 (BST)

> Not necessarily true, please see one counter-example above.

Let me rephrase it: "ILNP is specified such that it only requires 
changes to end-hosts".

I agreed earlier ILNP's decoupling of L from I is beneficial to 
infrastructure and could allow various enhancements - that matters 
not a jot until there's significant enough ILNP deployment so it can 
be counted on. To help the initial deployment, ILNP is purposefully 
end-host orientated.

Better?

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
Sometimes, too long is too long.
- Joe Crowe

---

From: Paul Jakma <[email-masked]>
Date: Thu, 17 Jun 2010 22:40:10 +0100 (BST)

On Thu, 17 Jun 2010, RJ Atkinson wrote:

>> know whether to calculate the ULP checksum over the full L+I or 
>> just the ILNP style I?

> This is described in detail in draft-rja-ilnp-intro.

It is yes, once you've read the Nonce draft. It might perhaps be 
clearer to refer more explicitly to the ILNP flagging function of the 
Nonce option in the intro draft.

>> Looking further at the docs, it seems this relies on the Nonce 
>> Option having stateful semantics to indicate "this remote IP knows 
>> ILNP". How will this scale exactly? E.g. imagine servers 
>> communicating with large numbers of clients.
>
> Existing TCP/IPv4 implementations for web servers already keep a 
> significant amount of session state for each TCP session. This is 
> known to scale adequately for very large numbers of TCP sessions in 
> several major operating systems (for example, in Solaris and 
> FreeBSD).

What I have in mind is the fact that TCP state can be burdensome 
enough that several OSes implement mechanisms to 'offload' that state 
back onto clients, through the "SYN Cookies" technique.

I.e. state is particularly troublesome when it is in kernel 
(unpageable memory in many OSes) and instantiable by arbitrary remote 
hosts. So I'm wondering what happens if malicious remote hosts 
deliberately set out to exhaust an ILNP resources by causing it to 
create more and more ILNP session cache entries. ?

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
Sigh.  I like to think it's just the Linux people who want to be on
the "leading edge" so bad they walk right off the precipice.
(Craig E. Groeschel)

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 17 Jun 2010 18:00:51 -0400

On 17  Jun 2010, at 17:40 , Paul Jakma wrote:
>> Existing TCP/IPv4 implementations for web servers already keep a significant amount of session state for each TCP session. This is known to scale adequately for very large numbers of TCP sessions in several major operating systems (for example, in Solaris and FreeBSD).
> 
> What I have in mind is the fact that TCP state can be burdensome enough that several OSes implement mechanisms to 'offload' that state back onto clients, through the "SYN Cookies" technique.
> 
> I.e. state is particularly troublesome when it is in kernel (unpageable memory in many OSes) and instantiable by arbitrary remote hosts. So I'm wondering what happens if malicious remote hosts deliberately set out to exhaust an ILNP resources by causing it to create more and more ILNP session cache entries. ?

Specifically...

Several existing OSs that do not use the "SYN Cookies" technique 
(that you mention above have) and do not have TCP offload
long been robust against TCP SYN flood attacks.  So there are 
other implementation strategies, not involving either TCP Offload 
or SYN Cookies that work just fine to make a TCP implementation 
robust against SYN flood attacks.  As an example, stock FreeBSD
on commodity x86 silicon, without SYN Cookies or TCP Offload, 
is widely considered to be robust in the face of a TCP SYN 
flood attack.

An ILNP Session flood attack consumes more attacker resources
than a TCP SYN flood attack consumes.  So a TCP SYN flood attack
would be cheaper/easier for an adversary to mount.  Attackers
generally aren't dumb, they generally are good at conserving 
their own energy and resources.

Separately, an ILNP Session flood attack impacts an 
ILNP-capable host less (in terms of state to manage)
than the equivalent TCP SYN flood attack affects a 
TCP-capable host.

More generally...

All useful networking protocols can at least theoretically
be subjected to (Distributed) Denial of Service attacks,
which is what you have postulated for ILNP.  

If I recall, this goes back at least to the Voydock & Kent paper 
over two decades ago.  (D)DOS attacks aren't preventable.  
Instead, the trick is to not create a new lowest work function
opportunity for the attacker.  ILNP clearly meets that criterion.

Thoughtful implementers ought not have difficulty handling this.
Quality of implementation matters today in our TCP/IPv4 world.
It matters for folks deploying IPv6.  It will continue to matter
in an ILNP world.

Just as the details of how to make a TCP implementation robust
against a SYN flood attack are very implementation-specific,
the details of how to make an ILNP implementation robust
against a new session flood attack likely will be very
implementation-specific.  So I don't think that any implementation
technique would apply to all ILNP implementation environments.

Cheers,

Ran

---

From: Paul Jakma <[email-masked]>
Date: Fri, 18 Jun 2010 10:19:13 +0100 (BST)

On Thu, 17 Jun 2010, RJ Atkinson wrote:

> (that you mention above have) and do not have TCP offload long been 
> robust against TCP SYN flood attacks.

FreeBSD has its own measures agaisnt SYN attacks though.

However, that's not relevant to the question. The question is:

When you have state that can be induced, then you need to consider 
how you will deal with malicious remote hosts (e.g. TCP SYN attacks; 
hosts with unbounded ARP caches have seen attacks on that state). In 
particular, it implies you will have to discard state.

So my question is: What happens to ILNP when a host is forced to 
discard an entry in the ILNP session cache? What's the behaviour?

> generally aren't dumb, they generally are good at conserving their 
> own energy and resources.

TCP SYN attacks are no longer a problem, because OSes take 
precautions and because it is well defined what happens when TCP 
implementations drop SYN state (e.g. it becomes harder to connect 
successfully to the host, but established connections are not 
affected (modulo any bandwidth impact of SYN floods)).

Further, the per-host costs of mounting attacks is irrelevant - you 
can hire botnets with tens of thousands of hosts. Host resources are 
cheap.

My question is, what will ILNP do in such a scenario? I stress again 
that TCP is just an example to show that protocols need to think 
about this, and my question is about what thought there is on how 
ILNP will behave.

Note that I am not trying to attack ILNP by considering attacks 
against it - just trying to strenghten the specs. :)

> Separately, an ILNP Session flood attack impacts an ILNP-capable 
> host less (in terms of state to manage) than the equivalent TCP SYN 
> flood attack affects a TCP-capable host.

I am interested in how ILNP degrades when attacks are made on its 
state.

> against a SYN flood attack are very implementation-specific, the 
> details of how to make an ILNP implementation robust against a new 
> session flood attack likely will be very implementation-specific. 
> So I don't think that any implementation technique would apply to 
> all ILNP implementation environments.

I think it helps if the protocol allows graceful degradation. So I 
think it's worth considering what happens to a protocol as/when any 
state it holds is discarded.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
What sane person could live in this world and not be crazy?
 		-- Ursula K. LeGuin

---

From: Paul Jakma <[email-masked]>
Date: Fri, 18 Jun 2010 10:24:30 +0100 (BST)

On Fri, 18 Jun 2010, Paul Jakma wrote:

> So my question is: What happens to ILNP when a host is forced to discard an 
> entry in the ILNP session cache? What's the behaviour?

Eek, not precise enough.. This should be: What happens to ILNP when a 
host is forced to choose to discard state from its session cache, 
e.g. because of resource limitations (be it state already in the 
cache, or state it wishes to insert)? ...

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
If you can survive death, you can probably survive anything.

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 18 Jun 2010 06:41:05 -0400

On 18  Jun 2010, at 05:19 , Paul Jakma wrote:
>> Several existing OSs that do not use the "SYN Cookies" technique (that you mention above have) and do not have TCP offload long been robust against TCP SYN flood attacks.
> 

Quality of implementation matters, for any protocol.  
I'm glad you agree with me about that.

> However, that's not relevant to the question.

It is DIRECTLY relevant to the question:

(1) it shows that real systems today can protect themselves 
    against flooding attacks that have more state per-new-session 
    than ILNP does, 
(2) and can do so without specialty mechanisms such as 
    TCP offloading or the "SYN cookies"method.  
(3) and also shows that different implementations need the
    freedom to use mechanisms best suited for that particular
    implementation, rather than having a one-size-fits-all
    solution imposed from above.

> The question is:
> 
> When you have state that can be induced, then you need to consider how you will deal with malicious remote hosts (e.g. TCP SYN attacks; hosts with unbounded ARP caches have seen attacks on that state). In particular, it implies you will have to discard state.

Disagree, at least as phrased above.  

It means that one has to manage state, which one has to do anyway, 
and isn't quite the same thing, and it also means that one wants 
to avoid having huge amounts of state per-session.  ILNP meets all
of those criteria already.

For example, some folks think of UDP as "stateless", 
but it actually has nearly as much state as TCP in 
a typical end system (e.g. in the Transport Control Block).

> So my question is: What happens to ILNP when a host
> is forced to discard an entry in the ILNP session cache?
> What's the behaviour?

First, recall that ILNP session state is generally short-lived
anyway.  

Work done at U. St Andrews on real world systems has experimentally 
confirmed a previous MIT LCS trace-driven analysis indicating that 
DNS caching (for things other than NS records) is essentially 
ineffective.  So there is no reason to keep things like inactive 
Locator state around for long periods of time even if a node is not 
being flooded.  The St Andrews work indicates that DNS TTLs as 
low as zero work fine even for *server* A records in a real-world 
operational environment.  (Details of the study will be published
eventually.)

For reasons like multi-homing and mobility, one would imagine that
normal ILNP implementations will have Locator lifetimes that are
quite short -- less than a minute in some cases.

Lost ILNP state will look rather like the situation where
a node moved, and the location update was dropped due to 
congestion somewhere along the path.  This scenario is 
already covered in reasonable detail.

>> than a TCP SYN flood attack consumes.  So a TCP SYN flood attack would be cheaper/easier for an adversary to mount.  Attackers generally aren't dumb, they generally are good at conserving their own energy and resources.
> 
> TCP SYN attacks are no longer a problem, because OSes take precautions and because it is well defined what happens when TCP implementations drop SYN state (e.g. it becomes harder to connect successfully to the host, but established connections are not affected (modulo any bandwidth impact of SYN floods)).

The same conceptual approach can work fine for ILNP.  It is entirely 
an implementation-specific matter whether that particular approach 
is adopted for ILNP.  

> Further, the per-host costs of mounting attacks is irrelevant - you can hire botnets with tens of thousands of hosts. Host resources are cheap.

Not irrelevant.  The work function of the attacker ALWAYS matters,
at lest to attackers, because they do consistently employ the
attack with the lowest work function for themselves.

> My question is, what will ILNP do in such a scenario? I stress again that TCP is just an example to show that protocols need to think about this, and my question is about what thought there is on how ILNP will behave.

You've missed my point:

	The same approaches that work for TCP today also can work 
	for ILNP.  So TCP is an existence proof that thoughtful 
	ILNP implementations will be fine.  

>> Just as the details of how to make a TCP implementation robust against a SYN flood attack are very implementation-specific, the details of how to make an ILNP implementation robust against a new session flood attack likely will be very implementation-specific. So I don't think that any implementation technique would apply to all ILNP implementation environments.
> 
> I think it helps if the protocol allows graceful degradation. So I think it's worth considering what happens to a protocol as/when any state it holds is discarded.

The standards-track TCP specifications don't include any special
text for SYN Floods.  

While RFC-4987, which is Informational status, was published in 
August 2007 and does cover the topic, that RFC appeared over a 
decade AFTER most TCP implementations were hardened.  That document 
describes a number of different protective mechanisms, but is 
not proscriptive and doesn't mandate any particular implementation 
approach.

Just as details of TCP implementations (and their protections) 
vary widely, details of ILNP implementations will vary widely.  
If the ILNP specifications required use of some particular 
mechanism today, then the effect would be to prevent implementers 
from tailoring defenses most suitable for their particular 
implementation.  Such specification is at least very premature today.

(Now, if you seek to add some specific text someplace, it really 
would be simpler procedurally for you to propose adding some 
specific text at some specific location in some specific I-D,
than to make me guess what text you are seeking where.   My 
crystal ball has been broken for years.  :-)

Yours,

Ran

---

From: Paul Jakma <[email-masked]>
Date: Fri, 18 Jun 2010 12:39:56 +0100 (BST)

On Fri, 18 Jun 2010, RJ Atkinson wrote:

> Quality of implementation matters, for any protocol. I'm glad you 
> agree with me about that.

Quality of implementation matters, but what is feasible to achieve by 
implementation is bounded by the protocol.

> First, recall that ILNP session state is generally short-lived

Doesn't it have to be at least as long as the session state of ULPs? 
Or at least, kept refreshed for that length?

> Lost ILNP state will look rather like the situation where a node 
> moved, and the location update was dropped due to congestion 
> somewhere along the path.  This scenario is already covered in 
> reasonable detail.

Ok, that's the kind of info I'm after. I know it's obvious to you, 
but you could point me toward where in the drafts this is described?

> The same conceptual approach can work fine for ILNP.  It is 
> entirely an implementation-specific matter whether that particular 
> approach is adopted for ILNP.

> 	ILNP implementations will be fine.

Unfortunately not all of us are as brilliant at seeing how TCP SYN 
state attack mitigation translates to ILNP. Hence it would be useful 
to the rest of us slow-thinkers, unable to see the obvious, if this 
could be explained explicitly, solely with reference to ILNP. ;)

E.g. it'd be useful in this to see the ILNP state machine described 
succintly, in one place, with perhaps a diagramme. (If that already 
exists, apologies, I'd appreciate a pointer). Perhaps also a fully 
worked example of how the ILNP protocol works.

As an example, imagine a long-lived TCP session (e.g. SSH) from an 
ILNP host to a server. Is this how it should work, if the server has 
no entry in its cache?:

 	client Ic			server
 	ICMP Locator Update ->
 					Lookup(Ic,nonce) == null
 					Insert(Ic,nonce -> L[])
 		<TCP/ILNP session establishes>
 		...
 					<due to resource concerns
 					 expunges its ILNP session
 					 cache entry for Ic>
 	<sends TCP/ILNP packet>
 					<what happens here?>

?

> crystal ball has been broken for years.  :-)

I'm still trying to understand the exact details of ILNP, so I don't 
think I can make suggestions for changes. Though, it might help 
dimwits like me if:

- there was a single document which succintly and precisely described
   the protocol (e.g. what's the implication of the "Valid Time" in
   the session cache? How/when do entries expire?). E.g. perhaps some
   of the more detailed text in the intro doc could be moved out of it
   and merged together with the Nonce and Loc. Update drafts.

- there were some worked examples somewhere (if they exist and I
   missed them, apologies). This could be useful in the concept/intro
   draft.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
Who goeth a-borrowing goeth a-sorrowing.
 		-- Thomas Tusser

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 18 Jun 2010 11:00:25 -0400

On 18  Jun 2010, at 07:39 , Paul Jakma wrote:
>> First, recall that ILNP session state is
>> generally short-lived anyway.
> 

Hmm.  The ILNP state could change very frequently, 
especially for a mobile node or a node of a mobile network.

So it is pretty easy to imagine TCP session state
being much longer lived than the ILNP session cache
information.

(In fact, one possible way to implement the ILNP session
cache would be to add that data to the Transport Control 
Block information already in many BSD systems.  I don't 
suggest that is optimal, but it is an example of an
approach that probably could be made to work.)

> but you could point me toward where in the drafts this is described?

draft-rja-ilnp-intro-03, Sections 3 & 4 would be good starting 
places.   Nearly all of the ILNP papers talk about mobility,
so they would also be useful.

(Mobile IP seems a quite dynamic topic area, with myriad
new optional extensions being proposed regularly.)

> exists, apologies, I'd appreciate a pointer). 

Off the top of my head, I don't think that ILNP even 
has a finite state machine, whether implicit or formal.  

ILNP is not nearly so complex as TCP with TCP's 3-way 
handshake and so forth.  Instead ILNP is a datagram 
protocol, just like IP.

Perhaps I need to go edit any uses of the phrase session 
state to instead say session cache information, in the 
interest of readability and clarity ?

The ILNP session cache is more similar to an ARP/ND cache
than to TCP session state held in a Transport Control
Block, especially if one is considering TCP with SACK
support (which I'm told is now commonplace).  

Perhaps the authentication-related processing descriptions
created the confusion that ILNP has a FSM ?  

(I don't think I can remove discussion of authentication,
as authentication is really important, but if that's the 
source of confusion, then I would want to try to edit text.)

ILNP cares about authenticating updates to that session
cache for the same reasons that (some) folks care about 
authenticating IPv6 ND, or are concerned about the 
lack of authentication in ARP.  

As the existing I-Ds discuss, the main difference from IP 
is that for an ILNP session, the initiator includes the 
Nonce destination option in its initial packets, and the 
responder (if one exists, after all ILNP also supports 
unidirectional communications) would similarly include a 
Nonce destination option in its initial response packets.

It isn't obvious to me that any of that involves creating 
a finite state machine, formally or otherwise.  I would urge 
folks NOT to think of ILNP as having a finite state machine, 
because I suspect it would impede one's understanding,
rather than advance one's understanding.

In any event, I'm not inclined to over-specify ILNP 
at this early stage in its development and specification.

Kindly recall that the RFC-793 TCP specification (1981)
did not include much detail on essentials like congestion
avoidance and control.  Those came years later (Van's
ACM paper in 1988, then RFC-1122 in October 1989) after 
there was more operational experience with the TCP protocol.

As of today, ILNP isn't a standards-track proposal being 
worked upon within the IETF, but instead an IRTF Routing RG
proposal that I hope to have published as an Experimental RFC.

For any networking protocol, both implementation and 
experimentation ought to be important parts of the 
development and specification process.  At least the
LISP folks seem to agree with this, and they seem 
to be going along quite well.  I don't think ILNP
is an exception to this well-worn, but quite correct, 
principle of protocol design. 

IMHO, what ILNP really needs at this point is some 
(freely distributable) running code.  Cisco's funding 
for non-Cisco work on LISP has been a real boost 
to their LISP effort, by providing more feedback 
through implementation and experimentation.
(I don't work for a big or rich company, so I'm
not in a position to fund any ILNP work.)

Now, as I've said all along, I am trying to make the
ILNP I-Ds more readable and more accessible.  So if anyone 
has concrete suggestions about existing text that is 
confusing, or about critical topics that aren't covered, 
or about the current document organisation, I'm very 
interested in hearing that.  (Revised I-Ds have been
submitted and should appear online in the next few days.)

> I'm still trying to understand the exact details of ILNP,
> so I don't think I can make suggestions for changes. 

Not to worry, there will be lots of chances to update
and refine specifications before anything is in any
danger of going onto the standards track.

Thanks very much for the thoughtful feedback.

Yours,

Ran