[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Separation vs. Elimination
Hi Michael,
I am perplexed that you don't consider Ivip to be a member of the
class of solutions known as "Separation" - the class of "core-edge
separation" schemes.
You wrote:
>> It doesn't matter that Ivip has a faster mapping system which
>> enables simpler mapping data and simpler ITRs and ETRs, or that it
>> is not intended to prevent edge devices from sending packets to
>> devices in the "core".
>
> I think the Ivip mapping system is exactly the part that doesn't fit. We
> feel strongly that we need to make a technical argument (not an economic
> one) as to why we aren't just moving the problem to the mapping system.
> Ivip has the only mapping system that proactively pushes mapping updates
> through the core.
I don't see how these issues affect the question of whether Ivip is
a core-edge separation scheme. I attest it is.
LISP, APT, Ivip and TRRP all move the problem to the mapping system
- and to ITRs and ETRs etc. But we are crafting the new mechanisms
to scale to much larger numbers of end-user prefixed (EIDs for LISP
and APT - I call them "micronets") then the global BGP system can
handle.
In addition, with Ivip, I intend there to be business arrangements
so that end-users pay for their use of the mapping system. This
means the whole thing can be run profitably and agreeably, scaling
to very large usage rates, since each mapping changes generates
revenue - rather than there being some end-users burdening other
parties with rates of updates which the other parties consider
unreasonable. I wouldn't claim that every part of the entire
mapping distribution system is necessarily covered like this, but
most of the top end would be - not the tail ends of the Replicator
system and the full database query servers themselves.
> Ivip has the only mapping system that proactively pushes mapping
> updates through the core.
I disagree.
APT and Ivip are the most similar proposals, in my view. They are
both hybrid push-pull systems. In both APT and Ivip, the full
mapping data is pushed to full-database query servers - Default
Mappers for APT. For both APT and Ivip these local full database
query servers provide fast, low-cost, reliable mapping responses.
This is totally different from the global query server arrangements
of LISP-CONS, LISP-ALT or TRRP. (Six/One Router doesn't have any
particular mapping system yet.) It is also totally different from
LISP-NERD's approach of pushing all mapping data to every ITR.
Ivip pushes the mapping fast and APT pushes it slowly. Ivip has a
distributed, but still reasonably centralised, push system which
fans out to all full database query servers. APT has multiple
islands, with more diffuse pushing of the updates from multiple
sources of mapping data within the islands. (I don't see any
benefit in APT islands - I think there should be one APT system.)
Your formal definition of separation is:
separating edge networks from the transit core, and engineering a
control and management layer in between.
I attest that Ivip does this. I see below that you mean more by
"separation" than I do.
. . .
>> I was just pointing out that I think that only Ivip and LISP with
>> PTRs do this robustly. I think APT's approach isn't so thorough.
>
> I guess we have to agree to disagree on this.
OK - but I don't understand how APT (with APT islands) can robustly
support packets from non-upgraded networks when there are two EIDs
such as /25 or longer, in the one /24, and the two end-user networks
are using ISPs in different APT islands, in a setting where it is
impossible to have advertisements for prefixes longer than /24
propagate across the DFZ.
> Also, keep in mind that APT is still under active development,
> particularly in this area.
I wasn't trying to say that APT could never support packets from
non-upgraded networks addressed to smaller EIDs - just that with the
current arrangements, in my understanding, that it can't.
. . .
>> OK. Your paper indicates that Elimination schemes can't support
>> packets from non-upgraded networks - at least that is my
>> interpretation of (page 4):
>>
>> Under Elimination, transit networks can do nothing but wait
>> for a unanimous action by all the edge networks before the
>> routing table begins to scale.
>>
>> Perhaps I am reading too much into that statement, but it is
>> profound benefit of Separation schemes that at least some of them
>> support packets from non-upgraded networks, compared to none of the
>> elimination schemes.
>
> I think you're reading a bit too much into it. =) We're talking
> specifically about scaling the routing table here. Of course,
> non-upgraded networks can still communicate with upgraded networks in an
> elimination scheme. However, if upgraded networks stop injecting their
> prefixes into the global routing table, they lose the benefits of
> multihoming when communicating with non-upgraded networks.
That is what I mean - with Elimination schemes, there is no way of
achieving the scalability goals whilst providing multihoming support
for packets from non-upgraded networks. So if you want to get
anyone - or more particularly most end-user networks - to adopt the
scheme, you must run it in a way that multihoming is supported for
packets sent from non-upgraded networks. Then, the only path to
scalability is to get practically every network to upgrade. Only
then can we achieve the scalability goal, by withdrawing the routes
from the DFZ.
> So upgraded networks will want to continue to inject their prefixes into
> the routing table until there are no more non-upgraded networks. So the
> transit networks' routing tables won't shrink until this happens.
Precisely - we agree: Elimination schemes are not a suitable
solution, in part because they could only provide scalability
benefits after essentially complete adoption during a backwards
compatible mode of operation for initial adoption, which provides no
scaling benefits.
However, it does not follow that all Separation schemes can
simultaneously achieve scaling benefits while providing multihoming
and portability support for all packets sent from non-upgraded
networks. Hence my mention of what I perceive are the limitations
of APT and TRRP in this regard.
>> That said, I think it is important to point out that this problem of
>> Elimination schemes - the benefits depending on how many other
>> networks have adopted it - also applies to some Separation scheme.
>> In particular, any scheme which can't provide multihoming and
>> portability for packets sent from non-upgraded networks means that
>> end-users adopting the system only gain usable, robust, complete,
>> multihoming and portability after all other end-user networks adopt
>> the system. Hence my mention of the limitations of APT's support
>> for packets from non-upgraded networks, of TRRP's preliminary
>> arrangements for this, and of Six/One Router's inability to do this.
>
> First, let me reiterate that we are talking in general about separation
> schemes in the paper, of course any particular design may or may not be
> able to achieve all of the possible benefits.
OK.
> Second, some separation schemes are not intended for deployment in
> end-user networks (a.k.a. edge networks) at all.
I don't understand this, since your definition is:
separating edge networks from the transit core, and engineering a
control and management layer in between.
The edge-network needs to adopt the new system. They either need
new address space, for instance if they are currently using PA
space, or they need to change the way their current PI space is
administered - or gain new Scalable PI space. There doesn't
necessarily have to be actual ITRs and ETRs in the edge networks,
but the concept of there being edge and ISP networks with or without
ITRs (or their Six/One Router equivalents) is crucial to the
operation of the Separation schemes.
> We are trying to make
> the point in the paper that transit networks are the ones that need the
> routing table to scale, and it is possible for transit networks to
> deploy separation schemes themselves, in theory, in order to directly
> address that issue. This is not possible for elimination schemes.
I agree it is not possible for elimination schemes, but I can't
think how transit networks could deploy any of the current
separation schemes without involving the end-user networks. Can you
give an example?
>> separating edge networks from the transit core, and engineering a
>> control and management layer in between.
>>
>> This doesn't match Ivip if "separation" means preventing edge
>> networks from sending packets to core addresses - but LISP, TRRP and
>> Six/One Router don't attempt to do this, and it is debatable whether
>> APT (eFIT??) could ever robustly achieve this.
>
> If your *provider* is encapsulating your packets (as in APT), of course
> you can't address anything in the *upgraded* transit core. But
> non-upgraded transit networks are effectively in edge space, so they can
> still be addressed.
I would have thought it more correct to say:
non-upgraded transit networks are effectively in *core* space, so
they can still be addressed. The Default Mapper has no mapping
for any address in a non-upgraded edge network, and to ensure
it can be reached from an upgraded edge network, it must forward
the packets without encapsulation.
(Of course, for hosts in non-upgraded edge networks to be able
to send packets to hosts in upgraded edge networks, one or
more border routers in the APT island need to advertise either
the upgraded edge network's EID prefix, or some other prefix
which covers this EID prefix.)
Only once all edge networks adopt APT will the core be truly
"separated" from all edge networks.
>> If "separation" means removing the edge address space from the core
>> routing system, then Ivip matches this description just as well as
>> LISP, APT, TRRP and Six/One Router. The differences in the mapping
>> systems are not relevant to the fact that all these systems achieve
>> this common "separation" goal.
>
> See above.
OK - so your use of the term "Separation" has a very different
meaning from the way I use it in my assertion that Ivip is a
"core-edge separation scheme".
I mean separation in the sense that the end-user address space is
managed by a separate system from the core, and does not burden the
core or contribute much or at all to its scaling problem.
You mean "separation" in that from an end-user network which adopts
the scheme, it is physically impossible to send packets to any core
address.
I understand this is a goal of APT. I don't think it is very useful
- and I think it could only be achieved after 100% adoption by all
edge networks.
But if this meaning of "separation" is your criteria, by which you
correctly exclude Ivip, then I don't understand why you include LISP
or TRRP. AFAIK, neither aims to physically separate all the edge
networks from the core as I understand you aim to do with APT.
>> From what you just wrote, I understand that APT's approach to the
>> technical limits and unfair costs in the current BGP system is to
>> reduce the number of BGP advertised prefixes and cope with many more
>> multihomed and portable end-user EID prefixes by handling these with
>> a "mapping" system, with ITRs, ETRs, Default Mappers etc.
>
> Right.
OK.
>> From what you wrote, I understand your solution to the same problems
>> occurring in the mapping system - overly large numbers of prefixes
>> and/or updates to the mapping of these prefixes, and the unfair cost
>> burdens this places on participants in the interdomain routing
>> system, in this case the ISP in an APT island - is purely a
>> technical fix. From that, I guess you mean that the APT mapping
>> system will be several orders of magnitude more efficient than BGP -
>> and that there is no arrangement for costs being paid by those who
>> benefit from the mapping changes, to those who are burdened by these
>> changes.
>>
>> In that case, I think the gains APT would provide - the increased
>> number of end-user prefixes the Internet will be able to handle
>> relative to whatever it can handle now - is roughly equivalent to
>> the extra efficiency with which APT manages mapping changes relative
>> to the efficiency with which BGP handles changed prefix advertisements.
>>
>> I guess you could get one, two or maybe three or four orders of
>> magnitude out of this.
>
> No, it's not an issue of efficiency. BGP and the Ivip mapping system
> both distribute two types of information: topology information (who is
> connected to who), and reachability information (which connections are
> currently working). These two types of information are indistinguishable
> in these systems.
OK - though the way BGP's routers handle packets and communicate
which prefix is advertised by which router is completely different
from Ivip's arrangement of ITRs, ETRs, query servers and fast-push
mapping distribution system.
In both cases, there is a global system which enables packets
addressed to some prefix to be sent to some router. Ivip only works
as an addition to the BGP system. BGP works on its own. BGP's
handling of changes is slow and expensive - and difficult or
impossible to charge end-users for when they make a change. Ivip's
handling of changes is intended to be much faster and less expensive
- while also making it easy to charge a small fee per update, a few
cents for instance.
> APT only distributes topology information in the mapping system.
For each micronet, Ivip's mapping system distributes the address of
the ETR to which packets addressed to that micronet should be sent
by every ITR. It is the responsibility of the end user to change
the mapping to some other ETR which works if the current ETR is not
working, or is not connected to their network. This requires Ivip's
mapping to be sent out fast - effectively in real-time - and it
simplifies the ITRs and ETRs and reduces the size of the mapping
information, since ITRs and ETRs are not involved in testing
reachability.
APT, like LISP or TRRP, has mapping information with two or more ETR
addresses (assuming a multihomed end-user network).
This mapping information is assumed not to need to be changed very
much, since APT's push (to the Default Mappers, from which ITRs pull
the mapping information they need) is slow by comparison to Ivip.
Consequently, each APT (or LISP or TRRP) ITR (or the ITR's Default
Mapper) needs to do its own probing of ETRs or use whatever
techniques to determine ETR reachability - then the ITRs (actually,
I think it is APT's DMs) need to make their decisions, based on the
mapping information, which ETR to tunnel the packets to.
> So the
> increased number of edge prefixes that an APT-based network can handle
> is relative to the (increasing) amount of BGP traffic that is due to
> reachability changes in edge prefixes.
Are you saying that a major efficiency - that is, scaling -
advantage of APT is that it doesn't convey reachability information?
Assuming this is the case, then I see it is true to this extent:
Your mapping doesn't need to be pushed as fast or as frequently as
Ivip's, or as fast or frequently as BGP would ideally propagate its
changes.
No-one else has drawn parallels between Ivip and BGP - so this is
interesting. Clearly they are completely different, and Ivip
assumes a core routing system - BGP. However, they are alike in
that both are in a hurry to communicate "reachability" information
across the Net.
Every time a BGP prefix is advertised, or no-longer advertised at a
given router, changes to this effect need to be propagated. The
changes may not need to go very far, or they may involve changing
the best path decision of every router in the DFZ.
Every time an Ivip micronet is mapped to some ETR, or not mapped to
it (typically it would simply be mapped to another ETR, but it could
be mapped to NULL, or its space could be reassigned to one or more
different micronets), the Ivip system needs to convey this quickly
to every full database query server. (And to any full database ITR,
but my current thinking is that there will be few or none of these -
just caching ITRs, some of which have a full database query server
integrated into them, or have one in the same rack.)
APT is not in a hurry to push mapping information to all the
island's Default Mappers.
Being not in a hurry is arguably a scaling benefit, as is not having
to push the mapping very often. However, one extra cost (compared
to Ivip) is that APT needs to push more complex, more voluminous,
mapping information. Another major extra cost your ITRs/DMs and
ETRs need to be much more complex than Ivip's because they must do
all the reachability testing and multihoming service restoration
decision making.
>> The Ivip approach is to provide firstly a more efficient mapping
>> system relative to BGP - as does APT - but also to technically
>> structure the mapping system so end-users can be made to pay for
>> each mapping change. This enables quite a lot of the mapping system
>> (not all, but most of it) to be run as a series of businesses. More
>> details are in:
>>
>> http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw-01
>>
>>
>> Then, there funding for the mapping system, so there are incentives
>> to build it, extend it, run it, make it more efficient etc. This
>> should greatly extend the maximum number of micronets, updates etc.
>> the whole system can handle, compared to what I understand is the
>> APT approach of a more efficient mapping system with costs falling
>> unfairly on the ISPs, with no backpressure on end-users to reduce
>> the number of mapping changes or the number of EIDs in the mapping
>> system.
>
> The costs are not falling *unfairly* on the ISPs -- they are the ones
> that stand to benefit. Again, the primary goal of APT is better routing
> scalability, which is a DFZ problem.
But what if an end-user network issued a mapping update every 10
seconds, 24 hours a day?
That would be as much of a burden on the ISPs in the APT island as
hundreds of thousands of ordinary end-user networks which only
changed their mapping every month or so. (In terms of mapping
traffic and processing it at each DM. In terms of storage, the
burden is the same.)
In this respect, APT achieves no benefits over BGP. Both APT and
BGP have to accept the arguably excessively frequent changes and
propagate them - and in both cases there is no way of charging the
originator of these changes to help deter them from making so many,
or to help pay for their cost across all the ISPs.
Ivip is completely different in this regard - there will be a small
fee per update.
So I think APT continues this problem of having to propagate
end-user initiated changes across many devices, without a fee. This
is what bedevils BGP - and is a significant part of the the heart of
the routing scaling problem.
> I suspect you will have a lot to say on this, so perhaps it should be
> moved to a separate thread, but I am curious: in regards to your
> economic model, what is stopping an ISP from charging their BGP-speaking
> customer for each BGP update today?
Other folks on the list would have a better idea of this, but I
think the current BGP system relies on trust and unsecured
announcements. To put up some kind of fence, administered in some
way to reject updates from networks which don't in fact pay a fee
per update, would require a major upgrade to all participating
routers. It would require some pretty fancy security arrangement
and my guess is that it is all too much of a headache. It would
also require some kind of organisation, accounting system, and
presumably some way of distributing monies to help ISPs pay for
bigger DFZ routers.
I figure it could be done. If this was all that was required to fix
the routing scaling problem, I think people would be working on it.
However, it doesn't alter the fact that the BGP system can't
reasonably be expected to scale to as many prefixes as there are
end-user networks which need portability and multihoming.
Fees for each BGP prefix and for each updates would help deter those
who advertise and change their advertisement of prefixes for
arguably spurious reasons, so it would marginally reduce the scaling
problem. However it wouldn't solve the scaling problem assuming we
want to have 10 million, 100 million or whatever end-user networks
with portable, multihomable address space.
>>>> Your description:
>>>>
>>>> LISP-CONS and LISP-ALT build a DNS-like hierarchical overlay to
>>>> retrieve mapping data when needed.
>>>>
>>>> strikes me as wrong. Neither has much resemblance to DNS. ALT is a
>>>> completely separate network, with its own BGP instance, using a
>>>> different but parallel address space, for sending mapping queries,
>>>> which are typically actually traffic packets. The responses
>>>> typically come back via the ordinary Internet, rather then the ALT
>>>> network. LISP-CONS is no longer being developed, as far as I know.
>>>
>>> Protocols aside, they seem quite similar to me -- in both cases, you
>>> query a hierarchy of servers, eventually getting the information you
>>> requested directly from the authoritative source. The major difference
>>> is that DNS queries start at the root of the tree directly, whereas
>>> LISP-ALT queries start at a leaf before ascending to the root.
>>
>> There are other differences which I consider significant, such as
>> the ALT network being a completely separate network, with routers,
>> BGP, tunnels etc. I think these differences are such that
>> "DNS-like" is an inadequate description.
>>
>> For instance, DNS queries go straight to the relevant server, via
>> the Internet. There often needs to be a query to one server in
>> order to find the address of another server to send a second query to.
>>
>> In the ALT system, a single query gets to the appropriate server -
>> there is no recursion.
>
> I think you mean, there is *only* recursion, in the sense of recursive
> DNS queries.
I mean "no recursion".
My understanding of ALT is that an ITR makes a query to some remote
query server it has no idea the location or Internet address of.
The query is typically the initial traffic packet for some EID
prefix for which it currently has no mapping.
It pops the packet into the ALT network, encapsulating it with a
LISP header with the ITR's address as the source address and the
initial packet's destination address as the destination address.
The ALT network's address is the same range of numbers as the
Internet's range (eg. the IPv4 ALT network has 0.0.0.0 to
255.255.255.255) but the routers in the network use these addresses
completely independently from any address those routers might have
on the Internet.
The ALT routers are linked by tunnels in the Internet.
Each ALT router aggregates some number of ALT routers below it. The
packet is passed along these tunnels and routers, just as if it was
on the Internet, but this is a different network. The packet's
destination address - the destination host EID address, ensures it
is forwarded to the authoritative query server for this EID. I
understand this is typically an ETR, but it need not be. This ETR
sends back the mapping reply directly via the ordinary Internet
(which is much faster and more direct than sending it back by the
ALT network).
There is no recursion. It is a conceptually neat scheme -
delivering the initial packet to the ETR even when the ITR doesn't
have mapping information (the ETR's address) - and at same time
having this constitute a mapping request. (APT has something
similar in a faster, local manner with the ITR sending packets to
DMs and getting a mapping reply in return.)
However, it is a global query server system, which I think is a
really bad idea in terms of delay and reliability. Worse still, the
physical paths likely to be traversed by query packets will often be
geographically much longer than the shortest geographical path.
LISP-ALT has no concept of recursion, as far as I know.
>> Also the query typically is the traffic
>> packet, so the ALT system functions as an early delivery system,
>> before the ITR has the mapping for this packet's EID prefix.
>> Another difference is that there is this whole new network, with its
>> own BGP system (scaling problems in that too?). The physical
>> location of the various routers in this system is likely to be
>> scattered all over the world, and the "highly aggregated" nature of
>> the ALT system leads to packets likely cris-crossing continents and
>> oceans as they traverse from source leaf and branch to trunk and
>> then to destination branch and leaf.
>>
>> http://psg.com/lists/rrg/2008/msg00229.html
>> http://www.antd.nist.gov/~ksriram/strong_aggregation.png
>>
>> I think that to call this "DNS-like" would give readers a
>> way-to-simple impression of LISP-ALT and its likely problems.
>
> Of course, a one-word description is necessarily way too simple. But
> this was only a six page paper, and explaining LISP-ALT is tangential to
> our point, so we couldn't do much better. I agree with you that LISP-ALT
> has many problems that DNS does not.
Yes . . . 6 pages:
http://conferences.sigcomm.org/hotnets/2008/cfp.html
is not much if you have something complex to write about.
Still, I think that it is misleading to describe LISP-ALT as "DNS-like".
. . .
> Notice the title of the slide: "What about Multipath ROUTING?" Our paper
> is talking about Multipath TRANSPORT, as are the rest of Mark's slides.
> Multipath TRANSPORT doesn't involve the routing system at all.
Thanks - I roughly figured out this distinction after I wrote my
last message.
>> Anyway, in your paper, it might be good to cite prior work on the
>> multipath approach you illustrate in section 5.
>
> If you mean the combination of multipath transport with separation, as
> illustrated, this is an original contribution, there is (AFAIK) no prior
> work.
OK.
> If you mean multipath transport in general, see Mark's slides (which you
> linked to above) and this reference:
>
> P. F. Tsuchiya. Efficient and robust policy routing using multiple
> hierarchical addresses. SIGCOMM Comput. Commun. Rev., 21(4):53–65, 1991.
OK - the OCR text is available for a fee:
http://portal.acm.org/citation.cfm?doid=115992.115999
>>>> I think what you wrote about failure detection is pertinent:
>>>>
>>>> Being able to effectively gauge the status of
>>>> multiple paths requires transmitting a large quantity of
>>>> data and sophisticated subflow control; not all applications
>>>> can continuously send large quantities of data (e.g.,
>>>> VoIP connections), and not all end points are suited to
>>>> perform complex control (e.g., small sensors).
>>>>
>>>> This critique also applies to ITRs trying to do reachability
>>>> detection in the non-Ivip core-edge separation schemes. I discussed
>>>> this in my recent message to Iljitsch.
>>> I'm not sure what your basis is for this claim -- in APT, for example,
>>> one data packet from one ER (a.k.a. ITR) to a failed DR (a.k.a. ETR) is
>>> generally sufficient to discover the failure.
>>
>> I think you must be relying on receiving an ICMP message either from
>> some intermediate router than the ETR is unreachable, or from the
>> ETR that the destination network is unreachable.
>>
>> I don't think that relying on ICMP messages to detect network
>> failures is robust. A failed or flaky part of the network can't be
>> relied upon to do anything, including successfully sending out ICMP
>> messages for every packet which goes to some router which has its
>> next hop in the faulty part of the network.
>
> No, we don't rely on ICMP in APT. We have our own control messages that
> are generated and processed at DRs and DMs. I believe the details (at
> least of previous versions of our failure handling) are described in
> most (if not all) of the APT-related documents.
OK - there is a message from the ETR to the DM of the sending
network that the ETR can't reach the destination network:
http://tools.ietf.org/html/draft-jen-apt-01#section-11.4
If the ETR's unreachability is reflected in its BGP prefix no longer
being reachable, this is handled in section 6.1.1.
But what if there is some network failure between the ITR and the
ETR? Section 6.1.2 handles this, on the assumption that the ITR can
send packets to the network in which the ETR resides, and that the
default mapper there, working with the internal routing system, will
be able to detect that the ITR sent a packet to the no-longer
reachable ETR.
OK - I see how you do this without relying on ICMP messages. You do
however rely on:
1 - BGP to tell the sending network's border router, and therefore
the ITR, that the ETR's network is unreachable.
2 - The DM in the ETRs network to tell the ITR (or the ITR's DM?)
that the ETR is unreachable.
3 - The reachable ETR to tell the ITR (or the ITR's DM?) that the
destination network is unreachable.
I think 3 should be OK - and probably 2.
However, there can be long delays across the Net with BGP
propagating a notion of unreachability. The destination network
could go off the air and nearby routers cancel their advertisements,
but other routers think their neighbour has a path, and advertise
that path's length. This does not necessarily get propagated
quickly, due to a delays in each router, including if there is a
flurry of such announcements when a major link dies. Also, there is
MRAI path hunting, depending on the structure of the routers.
http://www.firstpr.com.au/ip/sram-ip-forwarding/#BGP_hunting_MRAI_disc
which can delay the propagation of an unreachable condition by ~30
seconds for however many depths of this process there are.
>>>> Page 5 col 1 para 2
>>>>
>>>> I was unable to find any CIRL references - Google equated this with
>>>> "circle".
>>> Ah, it seems the URL was accidentally left out of the bibliography. Here
>>> it is:
>>>
>>> http://read.cs.ucla.edu/~frost/cirl/
>> CIRL: DDoS mitigation in eFIT
>> Chris Frost and Mike Mammarella July 13, 2008
>>
>>> Note that this is very much a WiP. We just cited it as a
>>> proof-of-concept.
>>
>> Thanks for this link. I stand by my critique of basing security
>> responses on the assumption that an encapsulated packet sent to an
>> ETR was sent via the ITR whose address is in the source address of
>> the encapsulating header - the attacker can send encapsulated
>> packets directly, with any ITR address in the outer header.
>>
>> In eFIT, perhaps it is impossible for an end-user host to send a
>> packet to an ETR, in which case my critique would not apply.
>> However, this is a highly idealised situation in which every
>> end-user network in the world adopts eFIT-mapped address space and
>> sits behind a router which refuses to forward any packet from inside
>> the network to the interdomain core, other than those which are
>> encapsulated already by ITRs and therefore are addressed to ETR
>> addresses, which are in the core.
>>
>> Still, in that situation, how is the border router to distinguish
>> between a packet it receives from an ITR inside its network, and an
>> identical looking packet created in a host controlled by the attacker?
>
> The answers to all of this are dependent on both how APT networks handle
> packets from non-upgraded networks, on the particular DDoS mitigation
> scheme, and on what (if anything) is done to ensure the authenticity of
> ITR addresses. These are all works in progress and/or future work, so
> I'd rather not speculate, except to reiterate that I don't see any of
> these things as unsurmountable.
OK - thanks for your detailed reply. No 6 page limits around here!
- Robin
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg