ment is, IMO, a major change.
I guess we must agree to disagree.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
current version of
draft-ietf-6man-oversized-header-chain essentially bans packets such as
thos in page 5 of
<http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-07>
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8F
maintenance, upkeep,
and advancement of the IPv6 protocol specifications and addressing
architecture. It is not chartered to develop major changes or
additions to the IPv6 specifications. The working group will
address protocol limitations/issues discovered during deployment
and operation.
Cheers,
--
Fe
period.
FWIW, I don't think anyone has proposed "if the chain is larger than X,
then drop".
We're just aiming at limiting the header chain length, *not* encouraging
router to drop when the header chain exceeds that length.
Cheers,
--
Fernando Gont
SI6 Netwo
drop v6 packets with extension
headers by default.
> just to be clear I'm not against the IETF documenting e.g. in a BCP, what the
> longest expected header chain should be.
Well, that seems more std track than bcp to me.
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si
rm; that is, no complaints yet ;)
Probably because nobody uses such headers in practice ;-)
Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Int-area m
re going to get to their intended
destination?
Some random folks, for some reason, starts sending those packets. He's
packets miserably die in the network. He comes to us, and we all say "oh
yeah... they are being dropped.. we know that". And the folk asks us
"why didn
;
> On the other hand - I, as an operator, may well decide to drop such
> packets.
Agreed.
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
On 06/13/2013 12:07 AM, Joe Touch wrote:
>
> On 6/12/2013 2:44 PM, Fernando Gont wrote:
>>> just to be clear I'm not against the IETF documenting e.g. in a BCP,
>>> what the longest expected header chain should be.
>>
>> Well, that seems more std track th
bytes, because otherwise
interoperability will be affected".
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
n expect them to work.
If we continue on the current path (do nothing), they will be
effectively killed. (see Brian et al's I-D, Warren et al's I-D, etc.).
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB
es: over 40% of packet drop rate for HBH, already. And quite a few
folks (e.g. Google) drop all packets that contain IPv6 EHs.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
you want to allow everything withing your
organization, or if you just don't care if your network melts down.
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
dividual -00 version. Nothing is set on stone.
Even it I don't agree with all of them, the filtering
> recommendations in this draft do seem to motivated by legitimate operational
> concerns, not blanket paranoia.
>
> I think we should move further discussion back to OPSEC and V6OP
the
> standards process in the first place. All because you think that
> anything you don't expect is an attack. It isn't. It just means you're
> not prepared.
We seem to be in disagreement. If anything, anything that I don't want
is not an attack, but rathe
ffman , Fernando Gont
, Fernando Gont , Fred
Baker , Fred Baker , Paul Hoffman
A new version of I-D, draft-gont-opsawg-firewalls-analysis-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.
Name: draft-gont-opsawg-firewalls-analysis
Revision
privacy, bad for firewalls
> as they are blind now and mostly useless
Yes and no.
If you mean TLS, it prevents DPI, but still allows for filtering based
on port numbers...
> - recommendation for NOT BLOCKING traffic over the Internet (except to
>
not appear to be new and have been mentioned
> in other documents already.
FWIW, the recommendations will be moved out into a separate document.
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_
-01.txt
Date: Tue, 13 Oct 2015 06:45:30 -0700
From: internet-dra...@ietf.org
To: Fred Baker , Fernando Gont
A new version of I-D, draft-gont-opsawg-firewalls-analysis-01.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.
Name: draft-gont-opsawg
houghts?
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
on needs for access
> (More common than you might think).
Yes. Or, at times, a user/app trying to circumvent unmanaged firewalls.
-- Ironically, at times these protocols are referred to as "firewall
friendly".
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
Ironically, at times these protocols are referred to as "firewall
> friendly".
>
> [Rick] The scenario makes no sense other than a mismanaged company
> frankly. You are essentially encouraging something against BCP. Even
> beyond security you will make it difficult to t
s more of a "fingers crossed" thing (if anything).
I'm not saying that I'm happy with the outcome, but rather that I think
that from an engenering point of view, it all looks like this ship has
sailed, and we should probably figure out how to deal with those cases
where fragmentatio
On 07/27/2018 05:15 PM, Tom Herbert wrote:
> On Fri, Jul 27, 2018 at 5:38 AM, Fernando Gont wrote:
>> Hi, Joe,
>>
>> On 07/26/2018 04:14 AM, Joe Touch wrote:
>>> Hi, all,
[]
>>
>> Side coments:
>>
>> It would all seem that there are tw
ook at RFC7872, t all looks like anything that is EHs
is dropped to some extent (while not included in the RFC, I also mesured
IPsec, and you get similar numbers). So besides the issues that are
specific to fragmentation, anything that is EHs gets dropped here an
there. -- and ding ECMP with t
ed over UDP to be able to survive NATs
and firewalls
Yes, and one hand is not nice to have to account for all types of
brokenness and filtering. OTOH, it would make any sense to enigneer a
protocol that only works on paper.
--
Fernando Gont
e-mail: ferna...@gont.com.ar || f
to make such assumption. Where you can't, you
may have to do stateful firewalling.
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
Haven't checked the I-D yet. Quick question: do you expect NATs parse
past this EHs to be able to do NAPT as they do nowadays?
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_
aders used with IPv4). Use of the fragment header with IPv4 is
> compelling because it could address deficencies in IPv4 fragmentation
> like the small ID field. It might also free up IPID to be used as an
> IPv4 flow label (RFC6864 states IPID can be arbitrarily set for atomic
> datagrams).
functionality should be removed.
+ fwiw, i don't care that much about the outcome, as long as there's
some level of convergence among specs, devices, and deployed
reality
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6netw
o be
supported. The message here is "unless you really know what you are
doing and you're in e.g. a controlled environment where fragmentation is
known to be supported, you shouldn't rely on fragmentation".
I wouldn't mind myself stronger advice, but this is what the wg s
Tom,
On 7/8/19 04:50, Tom Herbert wrote:
> On Tue, Aug 6, 2019 at 6:17 PM Fernando Gont wrote:
>>
>> Hello, Alissa,
>>
>> Thanks for your comments! Inline...
>>
>> On 6/8/19 23:
(and essentially IPv6 EHs, as per RFC7872).
That is: can you reliably use them? --Not at all... expect when you run
the network yourself.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96
Os for generating stuff that is
not possible to implement in a meaningful way, vendors for claiming they
support something when they do it in a very poorly way, or ops folks for
solving their problems with what they have at hand (instead of e.g. to
applying pain to vendors or SDOs, if at all p
On 7/8/19 17:07, Joe Touch wrote:
>
>
>> On Aug 7, 2019, at 7:01 AM, Fernando Gont > <mailto:ferna...@gont.com.ar>> wrote:
>>
>> On 7/8/19 16:30, Joe Touch wrote:
>>> Things that don’t work aren’t always either deprecated or security
>>&
he document we employ RFC2119
language to quote requirements from other RFCs, while in this specific
case we use caps to stress that this is the advice we are giving out.
FWIW, the advice hopefully triggers work for any protocols expected to
work across the Internet, and that currently rely on
gt; Alissa,
>>>>
>>>> Are you distinguishing between protocol development and application
>>>> development?
>>>
>>> I’m specifically wondering about application protocols (as distinct from
>>> other protocols) developed in the IETF (a
Pv6 the only guarantee is 1280. Therefore, in order to robustly support
> the minimum IPv6 MTU tunnels MUST employ fragmentation.
Isn't that an oxymoron? If fragmentation is fragile, if you need
something robust, you need to rely on something else
--
Fernando Gont
SI6 Networks
e-mail: f
On 3/9/19 18:39, Tom Herbert wrote:
>
>
> On Tue, Sep 3, 2019, 8:31 AM Fernando Gont <mailto:fg...@si6networks.com>> wrote:
>
> On 3/9/19 17:33, Templin (US), Fred L wrote:
> > Why was this section taken out:
> >
> >> 1.1. IP
On 3/9/19 18:41, Templin (US), Fred L wrote:
>
>
>> -Original Message-----
>> From: Fernando Gont [mailto:fg...@si6networks.com]
>> Sent: Tuesday, September 03, 2019 7:50 AM
>> To: Templin (US), Fred L ; Joe Touch
>> ; Alissa Cooper
>> Cc: Joel
roblem of widespread famine, and others.
I don't think that logic has solved any real problems in the real world.
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
On 4/9/19 00:02, Templin (US), Fred L wrote:
> Fernando,
>
>> -Original Message-----
>> From: Fernando Gont [mailto:fg...@si6networks.com]
>> Sent: Tuesday, September 03, 2019 1:49 PM
>> To: Tom Herbert ; Bob Hinden
>> Cc: Templin (US), Fred L ; int-ar
On 4/9/19 00:34, Tom Herbert wrote:
> On Tue, Sep 3, 2019 at 1:49 PM Fernando Gont wrote:
>>
>> On 3/9/19 23:33, Tom Herbert wrote:
>>> Bob,
>>>
[]
>> "fragile" means that it fails in an uncceptably large number of cases.
>> ~30 failur
ear. That seems pretty good to me. Which shows that implementers
> have taken IP fragmentation seriously and put in the hard work necessary to
> optimize the performance.
Have you ever checked the number of CVEs related to fragmentation?
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networ
On 4/9/19 16:46, Templin (US), Fred L wrote:
> Hi Fernando,
>
>> -Original Message-----
>> From: Fernando Gont [mailto:fg...@si6networks.com]
>> Sent: Tuesday, September 03, 2019 2:45 PM
>> To: Templin (US), Fred L ; Tom Herbert
>> ; Bob Hinden
>&
On 5/9/19 17:31, Tom Herbert wrote:
> On Wed, Sep 4, 2019 at 5:34 PM Fernando Gont wrote:
>>
>> On 4/9/19 18:26, Templin (US), Fred L wrote:
>>> Hi Ole,
>>>
>>>> -Original Message-
>>>> From: Ole Troan [mailto:otr...@employees.org]
would claim this is hand-waving.
FWIW, I don't remember seeing anything like this at the network layer.
(One might guess that in theory you *could* get feedback from upper
layers, but...)
This kind of thing is easier at *higher* layers -- such as trying to do
the 3WHS with the ECN bits set, and if y
idea that some set of layers
> inflates the headers (e.g., with signatures or key exchanges) beyond the MTU
> somewhere.
This would seem to be incorrect. IP has a minimum MTU of 68 bytes, and
IPv6 has a minimum MTU of 1280. Hence if you send packets smaller than
or equal to the minimum MTU, th
use small or large hop limit, depending
on whether you want to make sure that packets cannot be injected, or
that packets cannot leak out.
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
__
Thoughts or advice on the technical and/or procedural aspects will be
appreciated.
Thanks!
Cheers,
Fernando
---- Forwarded Message
Subject: Errata #5933 for RFC8200
Date: Thu, 27 Feb 2020 17:07:36 -0300
From: Fernando Gont
To: Suresh Krishnan
CC: 6...@ietf.org <6...@ietf.org>
Suresh,
x27;s not for lack of trying-- for instance I proposed a direction to
try for an engineering compromise in draft-herbert-6man-eh-attrib-00,
but saw little discussion on that.
Tom
On Thu, Feb 27, 2020 at 1:43 PM Fernando Gont wrote:
Folks,
If you haven't been following recent developments in
do better
than simply rubber-stamping any hacks a vendor with big pockets may
bring up.
Otherwise, I don't see the point of all this big structure.
For instance, we have an "Internet Architecture Board", which I guess
have a say on things that affect architecture?
Thanks,
--
Fern
lated at will *within the same organization that
published the specs*.
As noted by Jinmei here
<https://mailarchive.ietf.org/arch/msg/spring/XZ_D_cfPNNzXpi4_ZbuTidMTo4k/>
, I believe not only are we just rubber-stamping stuff, but also I
believe that our processes are being circumven
something they
actually sent.
EH removal breaks that.
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.o
are en-route to their intended destination, etc.
Thanks,
Fernando
On 27/2/20 20:21, Joe Touch wrote:
EH isn't a HBH option or extension.
Joe
On 2020-02-27 15:06, Fernando Gont wrote:
On 27/2/20 19:52, Joe Touch wrote:
FWIW - there are separable issues here:
- whether an IP heade
hitecture and principles that we're developing
specs within?
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
omething that won't have a single bit of
coherence, virtually impossible to digest by anybody else other by than
a limited group of people that just happens to know how everyone
violates each others specs.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:
like: "When there's stuff at
stake, only big vendors get to play, with their own rules".
I'll refer to Jinmei's email, which esentially conveys the same message
<https://mailarchive.ietf.org/arch/msg/spring/hmmgQygE0qIhOrt4Ii_1ANDQgHM/>
Thanks,
--
Fernando Gont
SI
On 27/2/20 23:18, Phillip Hallam-Baker wrote:
On Thu, Feb 27, 2020 at 8:52 PM Fernando Gont <mailto:fg...@si6networks.com>> wrote:
On 27/2/20 20:58, Robert Raszuk wrote:
>
[...]
>
> We need to ask ourselves what is more important ... quality of dat
- nobody knows what to expect, because one
document says one thing, and another says another thing.
There's a reason for which we have the "Update" and "Obsolete" tags in
RFCs...
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63
ep trying to push
similar ideas in other documents.
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf
On 29/2/20 23:19, Joseph Touch wrote:
On Feb 29, 2020, at 5:46 PM, Fernando Gont <mailto:ferna...@gont.com.ar>> wrote:
I did look at the protocols involved here; the ingress does add
headers but doesn’t appear to handle fragmentation.
That’s a non-starter if you want your p
low the insertion/removal of
extension header while the packets are en-route to the final destination.
I wished this conversation could go back to a honest one.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7
ocument.
I'm glad that there are more eyes now looking at what's going on.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Int-area mailing lis
7;t.
If it is, RFC8200 should have an explanation of how PMTUD and error
reporting works. And it doesn't have one.
In that light, I'm curious how folks can state that eh insertion/removal
is allowed.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
P
(> 1M
customers) DNS resolver in Germany in July. More than 2/3 of all DNS
traffic from that resolver to the Internet was over IPv6, less than 1/3
over IPv4.
At least for DNS, IPv6 is doing pretty good.
Modulo fragmentation? ;-)
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.
-considerations)
Date: Fri, 12 Feb 2021 18:50:48 -0300
From: Fernando Gont
To: IPv6 Operations
Folks,
In the aforementioned document
(https://tools.ietf.org/html/draft-gont-v6ops-ipv6-addressing-considerations),
we have tried to do at least three things:
1) Look at what we have and try to discuss
"
Does REQ-6 really apply here? (ICMP PTBs are not query/response messages)
Kind regards,
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
t they be deprecated as
> with the
> information request/response?
[suresh] I believe, It is not in the scope of this document to
deprecate ICMP messages or their use outside of NATs.
For this reason, the requirement for Address mask request/Reply
support for
e)
Nits
Section 6.3
> o >> The IP ID MUST NOT be reused when sending a copy of an earlier
> non-ATOMIC packet
S/ATOMIC/atomic/ ?
> RFC 1122 also suggests that fragments can overlap [RFC1122]. Such
> overlap can occur if successive retransmissions use differe
ug may be horrible, but if the mod introduces interoperability
problems, that's not good, either. -- not that it makes me happy.
>> Section 10:
>>
>>>>> During the transition period, a small ID space SHOULD be used to
>>> assist with debugging and detecti
ufficiently documented in an RFC. As a result, we're treating it as an
> error and silently dropping it. We're following the Postel Principle
> here - the data is unexpected, but since it could be non-malicious we're
> not treating it as such.
I don't follow.
It's about what you accept. And this
scheme is less liberal than the one specified in RFC 791.
(I'm not judgding the technical merits of your proposal... I'm just
arguing that IMO it does not follow Postel's Principle)
> IMO, reassembling them in ways that create undetectab
expect that it will be *replaced* in 5 years or so with
something else, I'd argue "Why not?". There are estimates of 15-20 more
years of living with IPv4, so
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 3
> in the world.
End-to-end transparency in the sense that every node will be reachable
from every node? -- IMHO, forget about it (see slide 13 of:
http://www.gont.com.ar/talks/lacnog2010/fgont-lacnog2010-ipv6-security.pdf)
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP
P-capable devices".
> Such devices are important when a cluster of devices is intended to act
> as a single device on the Internet, and a NAT can be an effective way to
> implement that front-end.
... and don't forget about "renumbering".
Thanks,
--
Fernando
t), needs to have state for that
"incoming connection". -- In general, there won't be such state, *or*
the firewall would need to be smart enough to understand the application
protocol to create such state before it's needed (so, again, forget
about the "dumb network").
Th
>
> UDP encapsulation of IPsec is a work around, specifically to get around
> the problems of lack of IPv4 address transparency i.e. NAT. It isn't an
> acceptable answer when NAT doesn't need to exist.
You're assuming that the only motivation to have NATs is address
e
Hi, Lars,
On 06/12/2012 04:36 AM, Eggert, Lars wrote:
> Hi,
>
> shouldn't we at the same time also be making the RFCs that originally
> registered these option numbers Historic?
You're absolutely right. The next rev will do this.
Cheers,
--
Fernando Gont
e-mail: fern
79 matches
Mail list logo
