that folks require (other than |I feel
like playing with EHs)
... the outcome is going to be the same.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
___
OPSEC mai
y!
Regards,
Fernando
Forwarded Message
Subject: New Version Notification for
draft-ietf-opsec-ipv6-addressing-00.txt
Date: Fri, 02 Jun 2023 07:26:18 -0700
From: internet-dra...@ietf.org
To: Fernando Gont , Guillermo Gont
A new version of I-D, draft-ietf-opsec-ipv6-addressing-00.txt
On 26/5/23 23:37, Tom Herbert wrote:
On Fri, May 26, 2023 at 1:44 PM Fernando Gont wrote:
On 26/5/23 18:01, Tom Herbert wrote:
On Fri, May 26, 2023 at 8:12 AM Fernando Gont wrote:
[...]
That said, I'm not that fine if invited to a party where, if anything, I
will only pay the
On 26/5/23 18:01, Tom Herbert wrote:
On Fri, May 26, 2023 at 8:12 AM Fernando Gont wrote:
[...]
That said, I'm not that fine if invited to a party where, if anything, I
will only pay the bills. So, I block everything that I don't use. e.g.,
I have no use for EHs in any of
ts are well-implemented.
Indeed. Datapoint:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=IPv6+extension+header
Smarter searching/keywords will at least double the results.
--
Fernando Gont
e-mail: ferna...@gont.com.ar
PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8 D1D5 4B94 E30
use to send weird packets to others.
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
The sales argument also argued that the packet structure led to improved
packet processing performance. -- which has not been well connected with
reality, though! :-)
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D
reason is bigger: additional cost or security risk. It
depends on the organization type.
Therein lies the issue: If I have no use for it, why should I accept the
risk? -- "no, thank you"... and move to an issue that actually requires
a lot of analysis to address :-)
Thanks,
--
Fernand
On 25/5/23 02:01, Manfredi (US), Albert E wrote:
-Original Message-
From: ipv6 On Behalf Of Fernando Gont
Given the amount of things that get connected to the Net (smart bulbs,
refrigerators, etc.) -- and that will super-likely never receive security
updates, you may have to
".
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
ar reactor" is the infrastructure that,
if compromised or DoS, causes clients to complain, money to be lost, and
eventually, staff to be fired.
Yes, I love to play with EHs in a lab. :-)
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar
PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8
channel independent of the application… it might be time that we accept that
this was a bad idea. Which deployment status has confirmed.
Agreed on this.
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
__
ayer 4+, well, that's probably long
gone (at least for r.g. enterprise and home networks).
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
th them can't be fixed.
Are your referring to the "transit AS" case, the "dest AS/network" case,
or both?
In any case, my comment was simply a two-liner email comment, as opposed
to full-fledged advice.
Thanks!
Regards,
--
Fernando Gont
e-mail: fe
. HbH and the like are mostly fine for the local link (e.g. MLD).
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
ck
implementation verified to be bug free and frozen in time that only
allows bug fixes (we need to avoid regressions!).
There's 20/30+ additional years of experience and tests of IPv4 and TCP
implementations than with these IPv6 features.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si
what security-minded folks tend to do with IPv6
EHs, particularly when there's currently no much reliance on them these
days.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D
was my bad '' this )and other references) is in our TO-DO list for
the next rev.
Thanks!
Fernando
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
___
OPSEC ma
-probe-attribution/).
The WGLC ends on Sun, Jan 29th, 23:59:59UTC.
Please review the draft and send comments/suggestions/opinions to the list.
Thank you!
--
SY, Jen Linkova aka Furry on behalf of OpSec chairs.
___
OPSEC mailing list
OPSEC@ietf.org
https:/
ider
incorporating/discussing?
Thanks!
Regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
f.org
To: Fernando Gont , Guillermo Gont
A new version of I-D, draft-gont-opsec-ipv6-addressing-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.
Name: draft-gont-opsec-ipv6-addressing
Revision: 00
Title: Implications of
ions on the Filtering of IPv6 Packets
Containing IPv6 Extension Headers at Transit Routers
Authors : Fernando Gont
Will (Shucheng) Liu
Filename: draft-ietf-opsec-ipv6-eh-filtering-10.txt
Pages : 40
Date: 202
/listinfo/opsec
--
Fernando Gont
Director of Information Security
EdgeUno
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
“This communication is the property of EdgeUno or one of its group companies
and/or affiliates. This electronic message contains information whi
the proposed insertion of the URI in PadN option could have
influence on the measurement itself;
You'd probably never use IPv6 EHs for probing, since the reliability of
the experiment will be degraded significantly -- unless you're actually
trying to measure *that* (as in
uot;.
Fixed.
These URLs in the document did not return content:
*
http://www.ipv6hackers.org/meetings/ipv6-hackers-1/zack-ipv6hackers1-firewall-security-assessment-and-benchmarking.pdf
Fixed!
These URLs in the document can probably be converted to HTTPS:
*
http://www.cisco.co
other current examples of this?
P.S.: Wasn't Apple requiring IPv6 support in all apps, anyway? :-?
Thanks,
--
Fernando Gont
Director of Information Security
EdgeUno
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
“This communication is the property of EdgeUno or one
with “Finally, we
> note that …”, this guidance seems very similar (repetitive) to the explanation
> already provided in Section 2.1.
I'd probably keep it, for clarity sake, since here we're arguing in
favor of reporting the drops,
> -- Section 3.2. Editorial. s/decisions in future/decisions in the future/
Will fix it.
> -- Section 4.3.9.5. Editorial. Recommend removing the unique “RFC-5570”
> style
> notation.
Yep. Will fix this one, too.
Thanks!
Regards,
--
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
f an AH is
> > present
> > presumably the advice from S3.4.5.5 applies.
>
> Probably not very relevant here, but the current IPSECME advice is to
> use
> ESP with null encryption rather than AH.
A pointer might be worth including. What document and section should we
be refe
/opsec
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
one way or another).
* Note:
Appendix A says "..such a sophisticated and powerful adversary" but
then Section A.1 says: "The techniques employed by this actor exhibit a
relatively low level of sophistication". So there would seem to be
something missing in between.
Thanks!
Regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
P at:
ftp://ftp.ietf.org/internet-drafts/
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/lis
es to ncscinfo...@ncsc.gov.uk
<mailto:ncscinfo...@ncsc.gov.uk>. All material is UK Crown Copyright ©
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP
eciated as an insecure methodology versus
ESP?
That'd generally be my take. But AH has never been formally obsoleted.
While double-checking this, I ended up finding this thread
(http://www.sandelman.ottawa.on.ca/ipsec/2000/06/threads.html#00063 ) in
which some folks have actually suggested th
uivalent.) The couple of
> times I've gotten to IEPG, I was struck by how it was
> higher quality than average IETF presentations. For
> me, I always really like finding out about cases where
> reality != theory and I bet I'm far from alone.
>
> So, I'd argue
data packet:
> = Flow Label: 0x0
>
> Which what was causing the problem.
>
At least some version of FreeBSD used to do the opposite: FL set to zero
during the TCP 3WHS, and non-zero afterwards.
--
Fernando G
what he's talking about.
>
> "By in large, this flow label changing behaviour has been traced to IPv6
> supporting CPE/firewalls, which change the flow label between the initial syn
> and the ack."
FWIW, FreeBSD had this behaviour -- without middleboxes involved ...
ha
https://www.ietf.org/mailman/listinfo/opsec
> This communication is the property of CenturyLink and may contain
> confidential or privileged information. Unauthorized use of this
> communication is strictly prohibited and may be unlawful. If you have
> received this communication in err
routers to parse?
> I don't see how you would conclude that from the above. What is needed
> is that whatever the parser needs to parse needs to be easy and cheap to
> parse.
At the end of the day, it ends up being the call of the folks running
the net. -- see RFC7872.
"I'm g
Folks,
This was posted today:
https://blog.apnic.net/2018/12/06/ddos-defences-in-the-terabit-era-pre-deployed-filters-future-initiatives/
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
mplementation limits in the lengths of the
extension chains they are able to process, or the performance with which
they can process the EH chains. In that sense, the IPv6 design is
actually a departure from IPv4, whose header format makes it easy to
skip over the option field and assess the "
killed SCTP. And the same goes for new
> protocols over IPv4.
Not exactly the same. If you are using a new transport protocols (*)
without any EHs, you have already found the upper-layer protocol. May
allow or drop, but that's it. With EHs, if you need to do packet
filtering or ECMP, you
enforce
checks on the input, usually based on what you'd expect or what one
might consider "sane". -- some extremists might call some of that a
deviation from "be liberal in what you accept".
Thanks,
--
Fernando Gont
SI
nterprise intermediate systems that process the
> contents of IPv6 EHs should discard packets that contain unknown
> options. Other intermediate systems that process the contents of
> IPv6 EHs should permit packets that contain unknown options.
>
> NEW: 4.4.5. Advice Intermediate syst
ption, to help folks with the aforementioned analysis --
regardless of what the outcome of scuh analysis is.
THanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
which the security
>>> implications cannot be determined. We note that this policy is
>>> allowed by [RFC7045].
>>
>> This looks like a sensible approach.
>
> I could live with that.
FWIW, I can live with that, too. UNless somebody screams against
ffects of
different types and options, and only advice to drop them when there is
a clear reason to do so. If you go through all the types we discuss,
you'll see that, for the vast majority, the advice is "pass it".
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP
rather different, and normally depend on the upper protocol
details. (e.g. TCP ports).
As noted in draft-gont-v6ops-ipv6-ehs-packet-drops, EHs can mess up with
the ability of intermediate devices to do their work.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
ou even expect non-standardized EHs to go through,
then, while nice, that expectation really needs a reality-check.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
t's not forbidden by rule, as far as I know. However, the
> draft is inconsistent in its use of SHOULD vs should (see my previous
> message for an example of a lower case should which might or might not
> be intended pseudo-normatively).
Ack. We will make sure there's consistent u
whose Next
> Header value is unknown -- i.e., IPv6 packets with unknown EHs **or** unknown
> transport protocols? Even for an IPv6 core router in the open Internet?
The document gos in line with RFC7045. Not sure what the issues is here...
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg..
previously,
> per email exchanges on the opsec list (and privately) circa
> 6 July 2018 with Fernando Gont. So I had expected to see a
> -07 revision appear with the agreed fixes, but maybe something
> fell through the cracks by accident. :-)
It may have been my failure. If that
the same rule to NDP and the RA-guard
>function described in RFC6105 [RFC6105].
The first para seems to have something missing (kind of "nodes should
drop first fragments that do not contain the entire ipv6 header chain").
Note: RFC6980 ba
ating whether they know of any IPR
> associated with this draft?
>
>
>
> Thank you
>
>
>
> -éric
>
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
6 addresses
> per node (per RFC 7934)
>
> - Section 2.7.2.6. Teredo & 6to4: moved to the end of the tunnel
> section + text about their current status
>
>
>
> Comments are of course welcome.
>
>
>
> -éric -merike -enno -kk
>
>
>
>
Hello, Ran,
Apologies for the delay in my response...
On 07/06/2018 07:57 PM, R. Atkinson wrote:
>
>
>> On Jul 6, 2018, at 12:24, Fernando Gont wrote:
>> It does. :-) (agreed on making the knob available)
>>
>> Regarding the advice, I'm wondering what wou
On 07/06/2018 05:49 PM, R. Atkinson wrote:
>
>> On Jul 6, 2018, at 10:41, Fernando Gont wrote:
>>
>> Hello, Ran,
>>
>> I realize that you had sent feedback on this topic before, but for sme
>> reason I had missed it -- my apologies for that!
>>
>&
stions here:
* What would you argue that de default value of this knob should be?
* In any case, I'd somehow rephrase the advice, since it implies a
requirement for a CALIPSO-specific knob --while we don't require any
option-specific knob for any other option.
Thought
ese docs in the
next rev.
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
On 03/06/2018 05:47 AM, Ines Robles wrote:
> Hi Fer,
>
>
> On 06.03.2018 10:36, Fernando Gont wrote:
>> [RFC] represents this document.
>>
>>Hex Value Binary Value
>> act chg rest
--- --- --- - --
0x23 001 00011 RPL Option[RFC]
0x63 011 00011 RPL Option(DEPRECATED) [RFC6553][RFC]
SO, while you don't say that elsewhere, it would seem to me that you
*are* deprecating it?
Tha
eaders
> Authors : Fernando Gont
> Will(Shucheng) Liu
> Filename: draft-ietf-opsec-ipv6-eh-filtering-05.txt
> Pages : 35
> Date: 2018-03-05
>
> Abstract:
>It is common operator pract
ress of the RPL
> network systematically; this overrides a rule in RFC 8200 but still makes
> sense in the particular case.
Will do.
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C
On 02/28/2018 01:29 PM, C. M. Heard wrote:
> On Wed, Feb 28, 2018 at 12:24 AM, Fernando Gont wrote:
>> On 11/28/2017 12:43 PM, Michael Richardson wrote:
>>>
>>> C. M. Heard wrote:
>>>> It seems to me that the option description and filtering a
this option at non-RPL routers. Isn't
this advice aligned with the fact that the option type bits note that
nodes that do not support this option should drop the corresponding packets?
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerp
El 20 oct. 2017 4:42 p. m., "Brian E Carpenter"
escribió:
> On 20/10/2017 22:53, Fernando Gont wrote:
> > Hello, Bob,
> >
> > On 10/04/2017 06:38 PM, Bob Hinden wrote:
> >>
> >> I also don’t think this is ready for a w.g. last call.
> >&g
re aggressive approach)-- but that would be a different
project.
Thoughts?
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
ay require changes in the draft.
We talked a bit about this. Best option seems to be to keep the current
text and add text regarding the changes in RFC8200 -- at the end of th
day, an operator will have to deal with both RFC2460 and RFC8200
implementations.
Thoughts?
Thanks,
--
Fernando Gont
S
Folks,
I did a thorough review of at least half of the document a while a go. If
you need further reviews, I volunteer for that.
Since I haven't looked at the I-F for a while, it would count as a "fresh
review", I guess.
Thanks!
Cheers,
Fernando
El 6/5/2017 03:56, "Merike Kaeo" escribió:
belong doesn't help, and in the long run takes more energy
(and creates more problems) than spending the energy in doing what is right.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
he specified
> behaviour is drop and send destination unreachable. That solves the
> problem for any packet obviously. And any prefix length assigned to
> the link.
How could RFC4443 possibly address this for all packets without formally
updating RFC2460?
P.S.: For a specification pov, this
.
>>> I question referencing opsec-ipv6-eh-filtering. It has wrong and
>>> outdated advice. E.g. on section of HBH header.
>>> The advice in ipv6-eh-filtering is essentially to ossify the network.
>>
>> Have you read the I-D? Because the I-D boils down to: &quo
fwd'ing, since there was a typo in the original email...
Forwarded Message
Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6
Date: Tue, 18 Apr 2017 12:10:37 +0100
From: Fernando Gont
To: otr...@employees.org, op...@ietf.ortg
CC: Gunter Van De Velde , v6...@iet
Folks,
I'd like to request a slot at the next opsec meeting for presenting:
* Filename: draft-gont-opsec-icmp-ingress-filtering
* Title: "Network Ingress Filtering: Defeating Attacks which employ
Forged ICMP/ ICMPv6 Error Messages"
* Presenter: Fernando Gont
* Slot: 10'
t in response to the comments from the
last meeting... but that's upto the ads/wg chairs.
Regarding the presentation in opsec, here's the info:
Title: "On Firewalls in Network Security"
Filename: draft-gont-opsawg-firewalls-analysis
Presenter: Fernando Gont
Slot: 20&#
FYI. We expect discussion to happen on the ops...@ietf.org mailing-list.
Forwarded Message
Subject: Fwd: New Version Notification for
draft-gont-opsawg-firewalls-analysis-02.txt
Date: Thu, 4 Feb 2016 22:58:06 -0300
From: Fernando Gont
To: ops...@ietf.org
Folks,
We have
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
>
ern fw features that exist today and I am not sure if
> it tries to convince readers about their need (because I don't think
> in today's world firewalling functionality can be rejected as
> unnecessary by anyone)
Please check many discussions in IETF circles. Many deem firewal
tempt to perform the kind of deep packet inspection and surgery
that is common with Network Address Translators [RFC2993]
And what we mean s not that FWs should not perform the kind of surgery
that NAT devices perform (e.g., modifying the application data stream).
Thanks!
Cheers,
--
Fernando
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
neficent social effects if it were believed. But
look only, and solely, at what are the facts."
Everything else I've authored has been about improvements, not "turning
it off"... and for instance, I've been IPv6 enabled for years... ;-)
Thanks!
Best regards,
--
Fernando
t; include them directly in the document. Or maybe I misunderstood what
> the table data represents?
All percentages are statistically significative... the measurements were
performed based on ALexa's top 1M sites
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6
ary
credentials).
> There are other
> application-specific ways of gathering information about active IP
> addresses that aren't listed here (the example that comes to mind is an
> attacker standing up a TURN server) but are probably also more trouble
> than they're wort
ions of nmap [nmap2012] implement this functionality.
This is a different feature: for local scans, you can just "ping" the
all-nodes link-local multicast address. But when scanning a remote
network, you can only target unicast addresses. And for remote address
scans, nmap does no
obvious from the algorithm described above,
>two bytes (bytes 4-5) of the resulting address always have a fixed
>value (0xff, 0xfe)
>
> Bytes 4-5, starting from 0 or from 1? The answer (which I can see from
> the example) is "starting from 1."
Good grief! mm.. ho
he -06 version of the draft. Could the
> authors
> PLEASE fix this, or else point out where in -07 this step is spelled out?
Good grief! It looks like the corresponding statement was mistakenly
dropped while editing the document. We've fixed the document now.
Thanks!
Best regards,
--
ght to the packet drop event in an
>implementation-specific manner as a security alert.
>
>5. In all other cases, DHCPv6-Shield MUST pass the packet as usual.
> END.
This is how we've fixed the document, with the addition of a "RATIONALE"
in bullet 4.
T
ponding to
>a target network (e.g. "0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." for
>"2001:db8:80::/32"), ...
>
> "2001:db8:80::/32" shuold be "2001:db8:80::/48".
You're absolutely right.
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg
,
> please reply to this email regardless of whether or not you are
> personally aware of any relevant IPR. We might not be able to advance
> this document to the next stage until we have received a reply from each
> author and listed contributor.
I'm not aware of any IPR on this document
f you are willing to volunteer to take notes or to be
> scribe.
>
> Brgds,
> G/
> ___
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
>
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6ne
andpoint, it shoudl clearly default to "drop".. otherwise
DHCPv6-Shield would be easily evasible by inserting an appropriate
number of IPv6 EHs.
Thoughts?
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25
On 02/09/2015 09:02 PM, Ted Lemon wrote:
> On Feb 9, 2015, at 6:48 PM, Fernando Gont
> wrote:
>> You're essentially proposing a hack to fix a known protocol design
>> flaw, instead of accepting the flaw, and allow DHCPv6-shield to
>> comply with the existing specifi
u're arguing against 6man's advice in RFC7045.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
> Either the next header is an unknown EH conforming to RFC 6564, or
> else it is a protocol header.
Are we in agreement that if RFC6564 is deployed, we say "bye bye" to new
transport protocols?
And if we are, is that the path you want to follow?
Thanks,
--
Fernando Gon
ith
> unknown extension headers, we are _also_ dropping packets with
> unknown protocol headers. That is the real harm of the language of
> the document as it is currently written.
You can't be worried about new transport protocols and at the same time
support RFC6564. If
t sufficient that it simply make it through the filter.
> Otherwise the host will not see it as a DHCPv6 packet, and the shield will
> have succeeded even though it passed the packet. So the packet has to use a
> valid chain of extension headers that the host can successful
e, it's
> already addressed in RFC 7045, and it's addressed correctly there.
> There is no need to strengthen the advice in RFC 7045 here, which
> this document currently does
Why do you think this document "strengthens the advice in RFC7045", as
opposed to it actua
7045, since that's the document on which we've
based our requirements.
So I don't understand what's the issue here, since we *are* complying
with the current (6man's) recommendations on the topic.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
advice on
the topic: RFC7045. That's why we provide RFC7045 as a reference.
If you don't like what the current version of the I-D says, you're not
only disagreeing with it and with the "RA-Guard IMplementation advice"
RFC, but also with the advice that 6man itself h
What this document should recommend is filtering
>>> of DHCPv6 packets from _clients_. If a rogue DHCP server can't see
>>> client multicasts because DHCPv6 shield is blocking them, then it can't
>>> know to attack DHCPv6 clients. This substantially limits the rogue's
>>> ability to attack D
arded, and allows the default behavior to be
that such packets be dropped.
cut here
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
1 - 100 of 206 matches
Mail list logo
