On Jul 28, 2014, at 9:52 PM, Marc Binderberger m...@sniff.de wrote:
Hello Dino,
thanks for this comment - that's an interesting point of view.
Hmm, how do the O (or RA in another draft) and the P bit fit into this
O-bit in LISP is not needed. I told the LUSP-GPE authors this. Because
2. The VXLAN-GPE draft should focus only on the VXLAN-GPE header and requires
the assignment of a new UDP port. The fact that the VXLAN-GPE header
closely resembles VXLAN may be convenient for implementers, but this protocol
by definition is not backward compatible with VXLAN.
If you
I'd like to give a special thank you to Terry.
Not only did he manage the admin part of being a working group chair very well,
he was always engaged technically and contributed quite a bit to the raw
technology. His practical operational experience and hands-on involvement in
the LISP beta
Hi,
Now that this document seems to be for a novice like me, may I ask some
stupid questions?
In the basic model where cases of multiple or virtual RLOCs for a xTR are
excluded:
1) When a node moves from one subnet to another within a LISP site, does the
EID change or not?
In
during the WG meeting.
This is the first edit after the interim meeting.
Albert
On Thu, Jul 17, 2014 at 5:15 PM, Dino Farinacci farina...@gmail.com wrote:
Like Joel, I would like to invite people read the document despite the late
submission.
One clarification, is this the first edit
On Thu, Jul 17, 2014 at 10:03 PM, Dino Farinacci farina...@gmail.com wrote:
But when an EID is assigned to a node (either static or via DHCP)
Is there a case in LISP that EID would be assigned to its interface rather
than to a node?
That is independent of LISP. I have done both while
DY and I are going private. If anyone wants a summary of this discussion DY
will provide one.
Dino
On Jul 17, 2014, at 2:14 PM, DaeYoung KIM dy...@cnu.kr wrote:
On Thu, Jul 17, 2014 at 10:33 PM, Dino Farinacci farina...@gmail.com wrote:
On Thu, Jul 17, 2014 at 10:03 PM, Dino Farinacci
2) the layout does not fit well with draft-farinacci-lisp-crypto-00. Are
there any plans to solve this? Should this at least be mentioned somewhere?
Both this draft and lisp-crypto are proposals to extend the LISP encap with
new features. I don't think they need to refer each other at
I am very concerned about the compatibility behavior of this.
If the sender is setting the P bit, and the next header, then he presumably
thinks that is useful to the receiver. If the receiver is ignoring the P
bit, and ignoring the field occupied by the next-header, how will the
, the P-bit is a change that doesn't really add anything new but does
something for another data-plane. That probably does not have a good
cost/benefit tradeoff.
Howver, service chaining is a completely different matter.
Dino
Fabio
On 7/8/14, 1:39 PM, Dino Farinacci wrote:
2
, both behaviors have their drawbacks and could be vectors for
attack.
Ron
-Original Message-
From: Dino Farinacci [mailto:farina...@gmail.com]
Sent: Tuesday, June 10, 2014 1
, operational practices, or people's heads, are not the topic for
the WG at this time.
PLEASE stay on topic, or we will never get our current work done.
Which means that peoples wonderful ideas on how to do more or better will
never get publsihed.
Yours,
Joel
On 6/12/14, 11:24 AM, Dino Farinacci
I am not aware of any IPR pertaining to this draft.
Dino
On Jun 10, 2014, at 8:09 AM, Damien Saucez damien.sau...@gmail.com wrote:
Dear all,
I am the document shepherd for draft-ietf-lisp-eid-block-08. In order
for me to complete the shepherd writeup, I would like first to ask the
authors
On Jun 10, 2014, at 9:57 AM, Ronald Bonica rbon...@juniper.net wrote:
Earlier in this thread, we agreed that when LISP is deployed on the global
Internet, mapping information cannot be gleaned safely from incoming LISP
data packets. Following that train of thought, when LISP is deployed on
, is it
even safe to glean that? I think not.
Ron
-Original Message-
From: Dino Farinacci [mailto:farina...@gmail.com]
Sent: Tuesday, June 10, 2014 1:04 PM
To: Ronald Bonica
Cc
Ron
-Original Message-
From: Dino Farinacci [mailto:farina...@gmail.com]
Sent: Tuesday, June 10, 2014 1:23 PM
To: Ronald Bonica
Cc: LISP mailing list list
Subject: Re: [lisp] Restarting last call on LISP threats
As I
Also, recall that large BCP38 holes exist in today's internet.
And I am going to repeat again, this is not a binary statement. That is, if a
BCP38 hole exists in one part of the network, source spoofing can still be
detected in other parts of the network.
Dino
I would defer to Dino and others on the list, but I do not believe that the
ETR does a reverse lookup on every packet. At least that is not the behavior
we observe. What we see happen is that the packet is decapsulated
Right Paul. We did not document an ETR doing reverse lookups to solve
in the packet to manipulate. This aspect
is on topic.
For our purposes, given that source address forging is known to occur, we
have to allow it in the threat analysis.
I agree.
Dino
Yours,
Joel
On 5/27/14, 11:04 AM, Dino Farinacci wrote:
Also, recall that large BCP38 holes exist
Ross, see my responses inline.
Detailed comments below. To summarize, these details include three threats
which are new to LISP and which are not adequately explained in the current
threats document:
(1) The Control Plane Threat: LISP allows a dataplane DOS attack (lots of
packets sent
Hi Paul,
The attack scenario that I envision is slightly different from the on that
you describe below:
- LISP is widely deployed. Tens of thousands of XTRs are deployed world-wide.
The mapping system data base contains hundreds of thousands of EID prefixes.
- The attack stream is
On May 27, 2014, at 5:18 PM, Ronald Bonica rbon...@juniper.net wrote:
RPB]
Exactly. Source EIDs are chosen to maximize the ratio of attack packets to
map-requests sent by the victim XTR.
This is what make the attack stream so different from a stream that a PiTR is
likely to send
Dino,
Today's Internet is not as fragile as you think. This mail traversed many
routers between my house and yours.
Ron, I know for a fact, it is fragile. I know most of the code that runs the
Internet. And you said yourself that uRPF is not used in many places, so that,
in and of
The attacker sends a flow of crafted packets to the victim XTR. Each packet
is a well-formed LISP data packet. It contains:
- an outer IP header (LOC-LOC)
- a UDP header
- a LISP Header
- an IP header (EID-EID)
- payload
Just like a regular packet I can send to your home router today.
: Dino Farinacci [mailto:farina...@gmail.com]
Sent: Friday, May 16, 2014 7:37 PM
To: Sander Steffann
Cc: Ronald Bonica; Roger Jorgensen; lisp@ietf.org
Subject: Re: [lisp] Restarting last call on LISP threats
Unfortunately this is not unlikely :( I certainly wouldn't consider it an
amazing
this will be create a
more
stable threat document.
Then Dino mention:
On Tue, May 13, 2014 at 7:47 PM, Dino Farinacci farina...@gmail.com
wrote:
snip
The main LISP spec (RFC6830) indicates if you want to trust the mapping
system you can use the gleaned information as soon as you receive
Unfortunately this is not unlikely :( I certainly wouldn't consider it an
amazing feat... BCP38 is not implemented as much as it should be.
I know there are many cases where BCP38 is not practice but more and more
access providers due uRPF.
You only need one in the path. And the ones that
I support this draft is ready to go to the IESG.
Dino
On Mar 20, 2014, at 11:26 AM, Joel M. Halpern j...@joelhalpern.com wrote:
The draft LISP EID Block has been revised to reflect the WG discussion and
comments received.
This starts a last call for this document, ending April 4, 2014.
Congratulazioni Luigi!
Your longstanding contribution to the WG has been key for the success of
LISP, and I'm looking forward to work with you in this new role.
I second the motion!
Dino
Fabio
On 3/18/14, 7:58 AM, Brian Haberman wrote:
All,
For those of you who have not
- LISP Data Plane Crypto
Document to be submitted
20 mins
Dino Farinacci
Document has been submitted:
http://tools.ietf.org/html/draft-farinacci-lisp-crypto-00
Dino
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org
LISP does not require remembering. And many (100s) sites are using addresses
they already have been using pre-LISP from non- corralled allocations.
Dino
On Feb 21, 2014, at 1:29 AM, Geoff Huston g...@apnic.net wrote:
On 15 Feb 2014, at 3:34 am, internet-dra...@ietf.org wrote:
A New
Hello Dino,
there was another question I forgot regarding the notifications: so
when the map-notification is not used as an ACK for map-register but is
actually informing the ETRs about events then how is the delivery
guaranteed? The underlying IP/UDP transport may drop.
The Map-Server
On 19 Feb 2014, at 00:45, Dino Farinacci farina...@gmail.com wrote:
Or if you want to solve only the cache-miss storm when ITR1 comes back
into the traffic stream then the ITR deflection has the advantage to
not require any cache-synchronization protocol, IMHO. The rate of
Map-Requests
My idea with the draft is to address all the extensions (with all the
required technical detail) to enhance LISP+SDN deployments, that's the reason
for the name. Please keep in mind that this is just a -00 version and
I understand what you are trying to do but when you say LISP+SDN that can
at 8:34 AM, Dino Farinacci farina...@gmail.com wrote:
[...]
However, vanilla LISP offers a limited feature set on terms of SDN
requirements. To position LISP as the foundations for a SDN
solution, advanced interaction between LISP elements and some
extensions to the stock
1. if you store the cache for next reboot, you will not experience
the miss storm when the traffic will come back to you.
2. if you shutdown an ITR, packets are forwarded to another ITR and
there is a miss storm as long as the prefixes in the backup ITR do not
cover those that where in
Hello Damien,
thanks for the reply!
If you have a solution to continuously synchronise ITRs caches, we
would be very happy to look at them and integrate them in the proposed
solution.
And I was curious to see a light-weight protocol extension from you :-)
Seriously, was wondering if
On Wed, 19 Feb 2014 11:41:19 -0800, Dino Farinacci wrote:
Hello Damien,
thanks for the reply!
If you have a solution to continuously synchronise ITRs caches, we
would be very happy to look at them and integrate them in the proposed
solution.
And I was curious to see a light-weight
for RLOC change detection ?
Set the L-bit to 0 in the LISP header if you don't want it.
Just trying to understand, not arguing about right/wrong/better/[...] .
Understand. Thanks for asking and wondering.
Dino
Thanks Regards,
Marc
On Mon, 17 Feb 2014 10:13:16 -0800, Dino Farinacci
I was thinking a draft title that incorporates flow would probably be
suitable, since you're extending LISP to deal with L4 flows. I was almost
going to suggest lisp-flowmapping, or flow mapping extension for LISP, or
something like that.. But I don't know enough about the other projects
http://tools.ietf.org/html/draft-rodrigueznatal-lisp-sdn-00
Alberto, enclosed are my comments. The draft text comes first and is indented
and my comments follow.
Abstract
This document describes extensions for the Locator/ID Separation
Protocol (LISP) to make it more suitable to be
Or if you want to solve only the cache-miss storm when ITR1 comes back
into the traffic stream then the ITR deflection has the advantage to
not require any cache-synchronization protocol, IMHO. The rate of
Map-Requests could be throttled to turn the storm into a breeze. The
method how to
Hello LISP experts,
have two questions, mainly to understand the context a bit better.
No prob Marc. Thanks for the email. I'll attempt to answer them but others can
chime in as well.
Q1: map-notify message.
maybe it's the name but I always expected this message is for the Map
Server
I agree the title needs to be more specific.
Dino
On Feb 17, 2014, at 9:59 AM, Michiel Blokzijl (mblokzij) mblok...@cisco.com
wrote:
Hi,
After reading this draft, I recognised the idea of using 5-tuples from the
LISP flowmapping project (I think there was another draft out there on that,
This draft seems to expect that IPSec tunnels will be set up by means outside
of LISP. That seems to contravene the premise of LISp that it can operate
without needing permanent / pre-established tunnel state.
Should this be tied to the work Dino described at the last IETF meeting on
Hi Joel,
This describes how LISP is used today in combination with IPsec (typically
GDOI is used to simplify key distribution).
So this is an existing best practice use-case document Fabio?
I think Dino's work is more forward looking, with two main goals: (1) combine
encryption with the
Could I have some status on this? There has been little to no discussion on
this topic.
Dino
On Jan 27, 2014, at 10:55 AM, Dino Farinacci farina...@gmail.com wrote:
Draft draft-farinacci-lisp-rig-02.txt has been previously requested to be a
working group document. There wasn't overwelming
Draft draft-farinacci-lisp-rig-02.txt has been previously requested to be a
working group document. There wasn't overwelming conscensus to do so, so its
status was not changed for about a year or so.
At this time I would like to request it to be a working group document (and to
actually bring
Do any routers count TCP/UDP checksum failures, much less
expose the count via SNMP?
Typically they do but only for packets destined to them. Much like hosts would
check the header checksum.
Dino
___
lisp mailing list
lisp@ietf.org
Hi,
I've decided to use NROffEdit for writing my CGEID draft (Cryptographically
Generated Endpoint IDentifiers).
While considering CGEIDs I got another idea:
Would it be possible to use LISP as routing protocol for mesh networks by
announcing the CGEIDs of neighbour-nodes as RLOCs of
Luigi,
Is this really what is going to happen?
If a PITR announces the entire /32 into the global Internet, it puts itself
on the forwarding path for the entire /32, and incurs the cost associated
with transporting traffic towards every site in that /32. This is supportable
only if
Assume that an operator deploys a PITR. What policy can that operator enforce
to ensure that it is compensated for all (or even most) of the traffic that
it carries across that PITR?
Through the same monetizing means it does today to attract any type of traffic
it wants to transit.
Dino
A partial answer that has been suggested is that the oeprator who deploys the
PITR is an EID allocator rather than a conventional / existing ISP.
Unfortunately, if LISp succeeds it is not clear that the compensation levels
can match the increasing demand for traffic in the critical
On 12 Sep 2013, at 20:29, Dino Farinacci farina...@gmail.com wrote:
So wouldn't be useful if an ITR which sends a Map-Request to the mapping
system, could say I know Mr. ETR that you have registered a bunch of stuff
to the mapping system, but can you return just the stuff I care about
. That and the previous lack of interest, is why I let the
effort go and didn't persue it further.
Dino
Yours,
Joel
On 11/20/13 1:17 PM, Dino Farinacci wrote:
Dino,
Sorry for the delay, I see this proposition just now.
Do you propose this capability in the context of VPN and/or NSC?
I
From: Dino Farinacci farina...@gmail.com
There is no need for a new message. That would complicate matters and
create more combinations to deal with when receiving responses.
Huh? Less complication than a(nother) wart on Map-Request/Map-Replies? I fail
There is no wart because consensus
This is similar to HIP's HIT based addresses. I think it is an interesting idea
and you should persue it by writing up a draft.
Dino
On Nov 8, 2013, at 4:16 AM, Rene Bartsch i...@bartschnet.de wrote:
Hi,
in the last week I proposed the idea of personal life-time EID-prefixes. What
Can you guys give us context. Robert, you didn't copy lisp@ietf.org with the
original message/claim from Xiaohu.
Dino
On Nov 8, 2013, at 10:51 PM, Robert Raszuk rob...@raszuk.net wrote:
Hi Xiaohu,
Prefix overlap within VPN is either on purpose injected into given VPN
or is due to VPN
That is not correct. With an EID block you would have:
Address in special prefix == address is an EID
Address not in special prefix != is not an EID
Luigi, I would say if Address is not a special prefix, it may be an EID but you
can only find out by doing a mapping database lookup.
Thanks for reply Geoff.
Closer to rough consensus,
Dino
On Nov 3, 2013, at 3:34 PM, Geoff Huston gih...@gmail.com wrote:
On 3 Nov 2013, at 5:09 am, Dino Farinacci farina...@gmail.com wrote:
So it appears that:
(1) People are all for experimenting.
(2) People may be all
we need a block for the
duration of the test period. We do not need a block for the hoped for full
success of LISP. If we really succeed, we can get an additional bigger block.
Yours,
Joel
On 11/1/13 10:33 AM, Dino Farinacci wrote:
I understand the importance of experimenting. But I
Geoff, LISP can route the entire allocated address space (but just not requires
it to be everywhere). So arguably, LISP can do this at much cheaper cost and
complexity.
The reason for a dedicated block is similar to why we have an address block for
IPv4 and IPv6 multicast. To experiment to see
And I think /16 is a good start. If LISP fails, the /16 will be usable again
in 6 years. If it succeeds, IANA will have to hurry assigning the /12 block!
;-)
Renne, I am not picking on you but this language seems to be used by a lot of
people. So you are just the latest messenger here. :-)
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
If it is difficult to explain what the experiment is about then I understand
that people are afraid it might be a bad idea.
I'll explain one experiment and will be
Chiappa) wrote:
From: Dino Farinacci farina...@gmail.com
We are not saying this entire block is being used for global deployment
of LISP. And no one is saying LISP can't succeed without this block.
...
It does not mean that the current forwarding paradigm does not work
or cannot work.
We
Make it a parameter of prefix/len.
And work the experiment in a /32
I could agree on both counts. And if you wanted to latch the /32 on a DNS name,
then implementations could make use of the level of indirection to allow the
prefix to change.
Dino
The term 'node' is used here as it used in the IPv6 work. (Maybe Terry?)
I remember Joel talking about how the IPv6 circle of folks use this term. But I
don't remember Joel mentioning he would provide a reference. What about RFC
2460? There is a definition of node in 2460 but it refers to a
I vote for the Part I/II option in one document.
Dino
On Oct 5, 2013, at 7:05 AM, j...@mercury.lcs.mit.edu (Noel Chiappa) wrote:
At the just-concluded Interim WG meeting, there was a certain amount of
discussion of the idea of splitting the Introduction document into two roughly
Joel - can you send the address of the location. Thanks.
Dino
On Sep 27, 2013, at 11:16 AM, Joel M. Halpern j...@joelhalpern.com wrote:
Reminder, the LISP interim is on Thursday and Friday, October 3 and 4.
Very rough agenda, sketched as a type, not yet reviewed with co-chair:
Webex
On Wed, Sep 25, 2013 at 9:03 PM, Dino Farinacci farina...@gmail.com wrote:
Hi Noel,
there's certainly no intention of keeping this out of the LISP WG, since
this is not part of the charter we just thought an individual submission
was more appropriate.
We just started from the very
.}
From: Dino Farinacci farinacci at gmail.com
the P-bit is being proposed for LISP.
For those who missed what this was all about (I sure did), there is a new ID:
http://tools.ietf.org/html/draft-lewis-lisp-gpe-00
LISP Generic Protocol Extension
As a personal ID, this ID
:
{This is mostly to the LISP WG; NVO3 - which I candidly admit to knowing
almost nothing about, but which I justt joined - may or may not care. Sorry
this goes on for a bit, but this is important. I hope people will take the
time to read it - it's not _that_ long.}
From: Dino Farinacci farinacci
text through out to reflect comments from Noel
Chiappa.
B.2. Changes to draft-farinacci-lisp-mr-signaling-02.txt
o Refreshing references and document timer.
B.2.
B.3. Changes to draft-farinacci-lisp-mr-signaling-01.txt
o Refreshing references and document timer.
B.3.
B.4. Chan
September 2013.
o Resetting timer for expired draft.
o Update author affliations and reference RFCs.
B.2. Changes to draft-farinacci-lisp-rig-01.txt
o Draft posted March 2012.
o Updated reference to LISP-DDT".
B.3. Changes to draft-farinacci-lisp-rig-00.txt
o Initial dr
So wouldn't be useful if an ITR which sends a Map-Request to the mapping
system, could say I know Mr. ETR that you have registered a bunch of stuff to
the mapping system, but can you return just the stuff I care about and more
importantly the stuff I support in my implementation?.
So I was
and LISP as identical as
VXLAN will have it, the P-bit is being proposed for LISP.
This is a proposal. The LISP working group must decide if the draft becomes a
working group document.
Dino
Lucy
Dino
Regards,
Lucy
-Original Message-
From: Dino Farinacci
On a related note, I find very general LCAFs a cause for concern. Particular
the JSON LCAF, which seems to allow the mapping system to reprogram the
packet processing hardware on the fly seems excessive. I understand it is
neat for experimentation. But how does something injecting a JSON
First, we will like to see a 5-tuple LCAF to allow mapping lookups based on
flows. In the attached TXT there is a proposed format. It allows to perform
exact match flow lookups, as well as best match lookups using port range and
prefix mask length. The proposed 5-tuple LCAF is based on
I think it would actually be quite interesting to use standard public key
encryption, rather than symmetric encryption in LISP. This would reduce the
need for negotiations, not require pairs of ITRs and ETRs to share the same
map server, etc. Admittedly it might not be practical for other
I agree that asymmetric encryption may be more desirable in theory, but in
practice symmetric encryption supports much higher performance loads
But with asymmetric we can use a two packet exchange (the Map-Request and
Map-Reply), store the public key only in the mapping database (no other
But what if the core didn't need to change and you key-n-encrypt before you
map-n-encap. In fact you could combine the key part and map part together
in the same lookup.
I'm just saying. :-)
Dino
On Sep 7, 2013, at 6:05 AM, Roger Jørgensen rog...@gmail.com wrote:
-- Forwarded
message:
From: IETF Secretariat ietf-secretariat-re...@ietf.org
Date: September 2, 2013 at 4:42:06 AM PDT
To: Dino Farinacci farina...@gmail.com, David Meyer d...@cisco.com,
Job Snijders j...@instituut.net
Cc: Terry Manderson terry.mander...@icann.org, Joel M. Halpern
j...@joelhalpern.com
I want to make sure we don't get off WG topic here. If the chairs feel it is
okay for me to reply to this I will.
However, I will certainly send you a private reply Heiner.
Dino
On Aug 5, 2013, at 4:51 AM, heinerhum...@aol.com wrote:
octet unicast address space extension.
But you let all up to NAT. This is really not a serve.
I cannot parse the above.
Dino
Sorry,
Heiner
(having nothing said about the dooming malicious/political problems yet)
-Ursprüngliche Mitteilung-
Von: Dino Farinacci farina
There are servers everywhere. Even not on the Internet. We leave in a world of
abuse. But I would like to think we live in a world where people help things
that serve.
Dino
On Jul 6, 2013, at 4:21 AM, Damien Saucez damien.sau...@gmail.com wrote:
On 06 Jul 2013, at 11:58,
De: lisp-boun...@ietf.org [mailto:lisp-boun...@ietf.org] En nombre de
cheng@zte.com.cn
Enviado el: jueves, 04 de julio de 2013 3:49
Para: Dino Farinacci
CC: lisp-boun...@ietf.org; lisp@ietf.org
Asunto: [lisp] 答复: Re: No LISP meeting for Berlin
Good idea, definitely support
Dino,
On 3/24/13 8:52 PM, Dino Farinacci wrote:
And also, link-local multicast groups are not explicitly joined.
The above is not necessarily true. The MLD specifications state that a
Report is sent for all multicast addresses except:
Yes, so do the IGMP specs but have not been
gaps is always present even without LISP.
Right, but the spirit of overlays is to solve such problems.
Dino
Isidor
On 27 Mar 2013, at 8:16 PM, Dino Farinacci wrote:
Right. But that only solves part of the problem. If you solve the whole
problem you won't need the mapping solution. What
As Jesus explained two separate attributes were defined for added
flexibility. For example it is possible to specify the receiver-ETR RLOC even
in the case that multicast transport is used. It may be needed to specify a
target for SMRs.
As for allowing the receiver-ETR to specify a
receive on DG.
Dino
Jesus
-Original Message-
From: Dino Farinacci [mailto:farina...@gmail.com]
Sent: Wednesday, March 27, 2013 10:02 AM
To: Isidoros Kouvelas (kouvelas)
Cc: lisp@ietf.org; Jesus Arango (jearango); Stig Venaas
Subject: Re: [lisp] draft-arango-pim-join-attributes
Right. But that only solves part of the problem. If you solve the whole
problem you won't need the mapping solution. What if 3 ETRs, all connected
to a multicast access network and the ITR also connected to a multicast
access network are connected together by a non-multicast network. Just
for
others without having to repeat the receiver RLOC address for each source.
Jesus
Okay, thanks for the response Jesus. That makes perfect sense.
Dino
On 3/22/13 3:55 PM, Dino Farinacci farina...@gmail.com wrote:
We would like to see some discussion on the list for
draft-arango-pim
It seems that while both these may be numerically identical (eg.
239.255.255.254), in terms of LISP, doesn’t (S,G) have to much more
Well yes. The spec used G to be the group address the users use to join to
and/or send to. And the spec says you COULD map one-to-one so if you are
to engineer such an example, are Options #5 and
#6 our only mitigation?
Ron
Dino
-Original Message-
From: Ronald Bonica
Sent: Thursday, March 21, 2013 6:12 AM
To: 'Joel M. Halpern'; 'Dino Farinacci'; 'damien.sau...@gmail.com'
Cc
that the entire attack
flow and all of the ICMP responses can get through.
Ron
-Original Message-
From: Dino Farinacci [mailto:farina...@gmail.com]
Sent: Thursday, March 21, 2013 1:06 PM
To: Ronald Bonica
Cc: Joel M. Halpern; damien.sau...@gmail.com; Noel Chiappa
1) pass each packet without verification
2) query the map cache for each packet. If no entry exists, discard the
packet and do not query the map server
3) query the map cache for each packet. If no entry exists, discard the
packet and query the map server
4) Create an entry in another data
On Mar 20, 2013, at 12:56 PM, j...@mercury.lcs.mit.edu (Noel Chiappa) wrote:
And I don't think there would be any _protocol_ changes needed to deal with
such a thing, just implementation changes. And since we don't normally
mandate implementation details, why can't we just say 'here's this
Joel,
Think that you have hit the nail on the head. So far in our discussion, we
have mention a few possible mitigations. These are:
- Option #3, as mentioned in the threats document
- Option #4, as mentioned by Dino
- Option #5, as mentioned by Noel
- possibly an Option #6, as
Inline
-Original Message-
From: Dino Farinacci [mailto:farina...@gmail.com]
Sent: Wednesday, March 20, 2013 2:15 PM
To: Ronald Bonica
Cc: Damien Saucez; LISP mailing list list
Subject: Re: [lisp] Need comments on LISP Threats Analysis
Do you agree that Options 1, 2 and 3
Thank you very much for your comments. Please see my responses inline.
You are welcome. I trimmed some of your email and included the parts that I am
replying to in this email.
According to hybrid model databases such like LISP-ALT [RFC6836] and
LISP-DDT [I-ietf-lisp-ddt],
701 - 800 of 854 matches
Mail list logo
