Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03

On Sun, Jul 27, 2014 at 2:21 PM, Dino Farinacci farina...@gmail.com wrote: 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

Re: [lisp] [nvo3] Comments on http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03

17:28:01 -0700, Tom Herbert wrote: On Sun, Jul 27, 2014 at 2:21 PM, Dino Farinacci farina...@gmail.com wrote: 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

Re: [lisp] [Int-area] [nvo3] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets.

On Fri, Jun 3, 2016 at 12:38 AM, Xuxiaohu wrote: > > >> -Original Message- >> From: Joe Touch [mailto:to...@isi.edu] >> Sent: Friday, June 03, 2016 12:34 PM >> To: Xuxiaohu; otr...@employees.org >> Cc: Softwires WG; n...@ietf.org; int-a...@ietf.org; lisp@ietf.org; >>

Re: [lisp] [tsvwg] Is it feasible to perform fragmentation on UDP encapsulated packets.

On Sat, Jun 11, 2016 at 10:11 PM, Lloyd Wood wrote: > Fragmentation should be strongly discouraged. > > if you've designed a tunnelling solution and you have fragmentation > happening as a matter of course, you've designed it wrong. > As mentioned before we do not always

Re: [lisp] [Int-area] Is it feasible to perform fragmentation on UDP encapsulated packets.

On Fri, May 27, 2016 at 7:59 PM, Xuxiaohu <xuxia...@huawei.com> wrote: > Hi Tom, > >> -Original Message- >> From: Tom Herbert [mailto:t...@herbertland.com] >> Sent: Friday, May 27, 2016 11:06 PM >> To: Xuxiaohu >> Cc: int-a...@ietf.org; Softwir

Re: [lisp] New Version Notification for draft-herbert-nvo3-ila-03.txt

On Thu, Oct 27, 2016 at 5:21 PM, Dino Farinacci wrote: >> - Restructured to make the draft more normative. >> - Addressed several comments from Pierre Pfister and others >> - Tried to make the description more generic and less datacenter >> virtualization specific (eliminated

Re: [lisp] [Ideas] WG Review: IDentity Enabled Networks (ideas)

hat one thinks of them, given that things like > HIP and LISP exist, and try tackle the ID/LOC split, I see no benefit > adding this extra layer of indirection with a privacy invasive > "Unique and Permanent" identifier which seems to be the only > non-overlapping part of this

Re: [lisp] [Ideas] WG Review: IDentity Enabled Networks (ideas)

On Fri, Nov 3, 2017 at 10:52 AM, Toerless Eckert <t...@cs.fau.de> wrote: > Thanks, Tom, inline > > On Thu, Nov 02, 2017 at 08:30:11AM -0700, Tom Herbert wrote: >> Toerless, >> >> That maybe true, but personal devices, such as smart phones and cars >&g

Re: [lisp] [5gangip] Fwd: New Version Notification for draft-nordmark-id-loc-privacy-00.txt

On Mon, Jul 2, 2018 at 10:01 PM, Jon Crowcroft wrote: > what we need is compact onion routing - maybe we could call it garlic routing. > > in all seriousness, if people are worried about privacy with regards > network operators, or state actors co-ercing network operators, at > this level, that

Re: [lisp] [5gangip] Fwd: New Version Notification for draft-nordmark-id-loc-privacy-00.txt

ate new attacks and that will have cost. It's a never ending problem, but it's worth it to continually try to solve IMHO. Tom > On Tue, Jul 3, 2018 at 5:14 PM, Tom Herbert wrote: >> On Mon, Jul 2, 2018 at 10:01 PM, Jon Crowcroft >> wrote: >>> what we need is compact onion

Re: [lisp] [Ila] LISP for ILA

On Tue, Mar 13, 2018 at 12:28 PM, Alberto Rodriguez Natal (natal) <na...@cisco.com> wrote: > Hi Tom, > > Apologies for the delayed response. Thanks for your time reading the draft > and for the feedback. See some comments inline. > > On 3/5/18, 4:42 PM, "Tom Herbert

Re: [lisp] [Ila] LISP for ILA

On Tue, Mar 13, 2018 at 3:50 PM, Alberto Rodriguez Natal (natal) <na...@cisco.com> wrote: > > > On 3/13/18, 1:05 PM, "Tom Herbert" <t...@quantonium.net> wrote: > > > > This is reflected below in: "While the mapping is being resolved via

Re: [lisp] [Ila] LISP for ILA

ilters and rate limitation"-- that guidance is not particularly enlightening or convincing. I am really hoping we can get something more concrete for dealing with DOS threats in a control plane for ILA. Thanks, Tom > Florin > > On Mar 13, 2018, at 4:27 PM, Tom Herbert <t...@quantonium

Re: [lisp] [Ila] LISP for ILA

or severely degraded. The recent Meltdown and Spectre exploits on CPU caches are a good reminder of how generally how hard it is to make caches resilient to attack and how the problem is never completely solved! Tom > Richard > > From: Tom Herbert > To: Florin Coras; > Cc: i...@ietf.org;

Re: [lisp] [Ila] LISP for ILA

with an algorithm that is able separate the bad packets from the good packets wrt the cache. Thanks, Tom > Florin > > On Mar 13, 2018, at 4:27 PM, Tom Herbert <t...@quantonium.net> wrote: > > On Tue, Mar 13, 2018 at 3:50 PM, Alberto Rodriguez Natal (natal) > <na...@cisco.c

Re: [lisp] [Ila] LISP for ILA

On Fri, Mar 16, 2018 at 11:08 AM, Dino Farinacci wrote: > Sorry about that but I did say from the Map-Resolver perspective. That is, > the node that receives Map-Requests from good acting ITRs/RTRs as well as bad > actors. “You” are the good and bad actors where we can’t

Re: [lisp] [Ila] LISP for ILA

On Fri, Mar 16, 2018 at 10:38 AM, Dino Farinacci wrote: >> Attackers don't typically set the evil bit in packets and will >> otherwise try to make their packets indistiguishable from legitimate >> traffic. Can you provide a reference to a specific solution with an >>

Re: [lisp] [Ila] LISP for ILA

On Fri, Mar 16, 2018 at 11:41 AM, Dino Farinacci wrote: >> Detecting that something is under DOS attack is not problem. It’s > > I do think it is a problem. Because you can’t tell sometimes if it is a > high-rate due to high demand from good actors. From the mapping system’s

Re: [lisp] [Ila] LISP for ILA

On Fri, Mar 16, 2018 at 12:17 PM, Dino Farinacci wrote: >> Such complexity is why I am still keen on the redirect model for a > > I hear you loud and clear. But we do the redirect model in LISP in many forms > as well. > >> mapping system. An ILA cache is an optional element

Re: [lisp] [Ila] LISP for ILA

gt; > Cc: David Meyer <d...@1-4-5.net>; i...@ietf.org; Tom Herbert > <t...@quantonium.net>; lisp@ietf.org; Paul Vinciguerra > <pvi...@vinciconsulting.com> > Subject: Re: [Ila] [lisp] LISP for ILA > >> A. Scalability >> B. Security >> C. Privacy

Re: [lisp] [Ila] Securing pull-based ID/LOC caches

On Thu, Mar 22, 2018 at 9:13 AM, Albert Cabellos wrote: > Hi all > > I am attaching a short paper describing a solution for control-plane > denial-of-service & overflowing attacks against pull-based ID/LOC caches. > The solution is based on implementing a per-source

Re: [lisp] [Ila] Securing pull-based ID/LOC caches

s should be much better than good users having packets dropped or blocked. Tom > > > > Dino > > > On Mar 23, 2018, at 11:46 AM, Tom Herbert <t...@quantonium.net> wrote: > > > > On Thu, Mar 22, 2018 at 9:13 AM, Albert Cabellos > > <albert.cabel..

Re: [lisp] [Ila] LISP for ILA

Thanks for posting the draft! Overall, I think the approach straightforward, and it's very nice that there is no change required to the ILA architecture. I have some concerns about the LISP control plane in terms of DOSability and scalability. Btw, LISP is not in Linux kernel because of concerns

Re: [lisp] [Ila] LISP for ILA

On Mon, Mar 5, 2018 at 5:00 PM, Dino Farinacci wrote: >> Looking at the map-reply message format, I am concerned about its >> size. By my count, it's 40 bytes to provide one record with one >> locator where record and locator are 8 bytes. If we need to scale a >> system to

Re: [lisp] [spring] IPv6-compressed-routing-header-crh

On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk wrote: > > Hi Mark, > > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary and a 32 > > bit alignment, > > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 network. > > > > As 32 bit SIDs are also the same size as

Re: [lisp] [spring] IPv6-compressed-routing-header-crh

the closed domains that it seems like source routing is targeted to. Tom > > > Ron > > > > > > > > Juniper Internal > > From: spring On Behalf Of Robert Raszuk > Sent: Friday, April 12, 2019 6:13 PM > To: Tom H

Re: [lisp] [spring] IPv6-compressed-routing-header-crh

On Fri, Apr 12, 2019 at 1:48 PM Mark Smith wrote: > > Hi Tom, > > On Sat, 13 Apr 2019 at 00:26, Tom Herbert wrote: > > > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk wrote: > > > > > > Hi Mark, > > > > > > > As MPLS SR SIDs are 2

Re: [lisp] [spring] IPv6-compressed-routing-header-crh

st-opt for an example. >> >> >> >> >> Ron >> >> >> >> >> >> Juniper Internal >> >> From: Robert Raszuk >> Sent: Thursday, April 18, 201

Re: [lisp] [spring] IPv6-compressed-routing-header-crh

ts on that draft, suggestions. > > Regards, > Greg > > > On Fri, Apr 12, 2019 at 3:09 PM Tom Herbert wrote: > >> On Fri, Apr 12, 2019 at 1:48 PM Mark Smith >> wrote: >> > >> > Hi Tom, >> > >> > On Sat, 13 Apr 2019 at 00:26, Tom H