e wg didn't
want that in -- and I did raise the issue a few times. So what we have
is what the 6man wg had consensus on.
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
semble-inspect-and-refragment... or even reassemble the TCP stream
(e.g. think about a SSL/TCP-based VPN...)
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
gt; discussions we had earlier and the resulting draft from Mark
> Andrews on what to do when the header chain spans multiple
> fragments? Are we trying to keep the header chain all within
> the first fragment or not?
Yes.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6n
On 10/02/2013 08:50 PM, Tom Taylor wrote:
> Just a trivial change: "including" -> "subject to"
Agreed. But I can fix it this after IETF LC or even durng AUTH48.
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C
nts, and sends an ICMPv6
error message due to the discard, then the ICMPv6 error message MUST
be Type 4 ("Parameter Problem") and MUST use Code TBD ("First-
fragment has incomplete IPv6 Header Chain").
?
> 5. I would suggest adding a reference to 2460 for the 12
ing askance at IPv6 fragmentation is not
> logical if one is not at least as concerned about TCP, which does
> NOT seem to be widely blocked
FWIW, I came across this (worth-reading) article:
<http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/>
--
covered (and are not being actively exploited), it
> takes significant time to regression test / smoke test new code, and
> significant time to upgrade an entire network. It therefore makes
> sense to try and limit the exposure / attack surface…
I understand. At the end of the day, the
ments, no matter which device they are
directed to.
> Anyway, I figured folk might find this interesting:
> http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130925-ipv6vfr
I did find the pointer interesting (thanks!). If folks know more about
this vulner
ant to
use TCP. There are a bunch of attacks that can be (by far) more
devastating than the fragmentation-based ones (see
<http://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf>).
Thanks,
--
Fernando Gont
SI6 Networks
e-mail:
resses, it certainly applies to those technologies (and
probably is as "general" as you can get in this respect).
>>> Nits ====
>>>
>>> indentation of /Cryptographically Generated /
>>>
>>> indentation of
se specified in [RFC2464])"
with
"(such as those specified in [RFC2464], [RFC2467], and [RFC2470])"
The only downside is that there are many instances of this, and hence
the text would become a bit cumbersome.
> Nits
>
> indentation of /Cryptographically Gen
Doesn't that make things ("slightly", if you want) harder for an
implementer?
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
is removed prior to publication, I guess one
has to navigate IANA's site, or Google for he registry??
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
-
s. Hence you can have your own network
be an amplifier to attack a third party.
Not to mention that if you're employing e.g. an openvpn Ethernet
bridge, it becomes fuzzy what's your local link (i.e. real links vs.
"virtual" link).
IMO, this is the kind of feature
Group of the IETF.
>
> Title : A Method for Generating Semantically Opaque Interface
> Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)
> Author(s) : Fernando Gont
> Filename: draft-ietf-6man-stable-privacy-addresses-13.txt
&
27;s go with normative.
Ok. Please let me know if we're fine with the above change (para that
goes in the Terminology section + normative reference) and I'll rev
the I-D.
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C
MHO it would be
incorrect, as discussed with Brian). (please see the P.S., anyway).
> I agree that we should publish these two documents together.
+1 for this. Isn't there a way to request this without a normative ref?
P.S.: Ple
IANA is .xml based.
>>
>> Do you know which file is the authoritative one?
>
> If you follow links from the IANA home page, you get to
> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
> As far as I know that is the primary reference.
Ok, I will
days IANA is .xml based.
Do you know which file is the authoritative one?
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
IETF IPv6 working group m
been specified in [RFC2460] itself and in
other later documents.
(which IMO would still be fine, since we don't really need to provide
the full list here)
Thoughts?
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4
on't think
> this attack vector is that serious.
That might help preventing an attacker to exploit this against an
arbitrary system, but not against all nodes.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networ
ng used with
other address configuration mechanisms, such as DHCPv6 or static address
confguration"
at the end of Section 1, right before the "terminology" paragraph?
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C
case specifically).
Please see above. Moral of the story: be proactive. A bad idea is... a
bad idea. So if you don't find a scenario where a bad idea can be
harmful, that doesn't mean attacker won't find it, or that such scenario
doesn't exist.
Cheers,
--
Fernando Gont
SI6 Net
't that specifically warrant more text on the subject?
The Network_ID parameter is optional. If you can come up with a
Network_ID for your network, you can use it. However, in the case of
Ethernet I don't think there's an obvi
implementors.
That's left unspecified, since it might be tricky: there's might be more
than one local router, for redundancy purposes -- but since it's the
same network, you'd want your addresses to be stable.
That's why in the SSID example we use the SSID, a
L
> datagrams, which is at the heart of the subject matter of
> draft-bonica-6man-frag-deprecate.
The wg discussed this, and I seem to recall that the outcome was that we
were not ready to ban the use of fragmentation, but rather that we
should move away from it.
Cheers,
--
Fernando Gont
S
n 4).
>
> I agree that this all seems fine in theory. Are we collectively
> convinced this will not lead to tragically (IPv6-)orphaned machines in
> certain scenarios?
Sorry, what are the scenarios you have in mind?
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.c
e
>>> they are experimental values defined by a standards track RFC. Go figure!)
>>
>> I think we might be able to do both "1)" and "2)" above by adding a tag
>> along the lines of "not expected in the public Internet"? (with the
>> impl
so tricky, because
> they are experimental values defined by a standards track RFC. Go figure!)
I think we might be able to do both "1)" and "2)" above by adding a tag
along the lines of "not expected in the public Internet"? (with the
implication that "it&#x
but in practice,
> there are various methods of forming such an interface identifier.
s/that that/that/
* Section 1
> Finally it updates RFC 4291 accordingly.
Missing comma right after "Finally".
* Section 2:
> If not, the problem will be detected by duplicate address detec
y not just avoid counting, note that some "ext headers were specified
in [RFC2460] and others in subsequent RFCs", and point to the
corresponding (upcoming) IANA registry for ext headers?
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 666
rved that certain firewalls do not even
>handle all the extension headers standardised in RFC 2460, including
>the fragment header [I-D.taylor-v6ops-fragdrop], causing fundamental
>problems of connectivity.
I'd probably s/connectivity/interoperability/
* Section 1:
> It ca
HO, I wouldn't personally opt for changing the title, since I think it
conveys the information it is meant to convey.
That say, if we (wg) want to go that path, something along the lines of
what I suggested above (essentially *your* suggestion, with a minor mod)
would seem to be the best alt
omments have
not been addressed, since you've stated that they have.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
IETF IPv6 work
lar case of someone leaking a secret key above
(but we still call them "secret").
The best thing a reader of this document can do is read the I-D we're
co-authoring with Dave and Alissa. Whatever title we were to chose won't
help the reader avoid the ned to do that.
Cheer
>> Me, I don't care much about the title. However, given that folks
>> have become used to refer to this scheme as "stable-privacy
>> addresses", and that so far alternative titles don't seem to do a
>> much better job, I'd leave the title &
es are
"stable per network", too.
Me, I don't care much about the title. However, given that folks have
become used to refer to this scheme as "stable-privacy addresses", and
that so far alternative titles don't seem to do a much better job, I'd
leave the
problem
> for them. :-) if so, Pascal can explain this better.
Unless IOS has became free software, it looks like you're not reading
what I'm writing.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 74
SSAS, the
> problem of using CGA is not IPR otherwise without any reason people accepted
> SSAS and I did not need to put effort to convince people :-).
The problem of your scheme is that is an extremely complex way of doing
something that can be much simpler.
IPRs *are* a problem. If you think y
easonable and Non-Discriminatory License to All
> Implementers
This is a non-starter for many free-software projects.
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
with the current title. Besides, the
community has become used to refer to this method as
"stable-privacy-addresses".. so changing the title at this point would,
IMHO, only contribute to confusion.
Thoughts?
Thanks,
--
Fernando Gont
SI6 Networks
e-mail
pseudo-CGA as I had to change
> some inputs so nobody can claim about IPR for this algorithm. :-)
I won't fight this one with you, Hosnieh. You have received my input.
It's up to you what you do with it.
Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PG
esides, there are IPRs on the CGA algorithm... but RFC4941 itself
doesn't have any. SO this document would essentially IPR-encumber
RFC4941 -- the farther that you can get from that, the better, I'd say. :-)
Cheers,
--
Fe
: A method for Generating Stable Privacy-Enhanced
> Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)
> Author(s) : Fernando Gont
> Filename: draft-ietf-6man-stable-privacy-addresses-11.txt
> Pages : 25
> Date
to that RFC , I just briefly mentioned that the node
> "MIGHT" follow the other external policies for the lifetime and “Might”
> not follow those of RFC 4941.
>
>
>
>
>
> If there are any other issues that I should consider for this draft,
> ple
r proposed way forward.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
IETF IPv6 working group mailing list
ipv6@ietf.org
Administ
w implementations), nor we're advising networks to
drop fragments.
-- i.e., something along the lines of what we did in RFC 6093 for the
TCP urgent mechanism.
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8
g a
non-native English speaker, at times it gets hard to dynamically adapt
:-) to the different accents).
Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE
ized IPv6 Header Chains
> Author(s) : Fernando Gont
> Vishwas Manral
> Ronald P. Bonica
> Filename: draft-ietf-6man-oversized-header-chain-03.txt
> Pages : 12
> Date
> merits or lack thereof.
Again: Why is this more special in v6 than in v4?
-- You seem to be ignored the "questions" that I've asked.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
some
implementation does something stupid about it, then I wonder what we'd
be left with. -- for instance, you should be deprecating Neighbor
Discovery, because many implementations do things such as allowing the
NCE to consume all memory, not doing any sanity checks on the received
link-la
hey employ multicast... which might mean that they need to send such
"large" UDP datagrams).
** Therefore **
Considering the above, I guess I'm in the camp of "avoid fragmentation
where possible". However, I don't think I'd go as far as deprecating it.
Jus
On 06/27/2013 06:14 AM, Fred Baker (fred) wrote:
>
> On Jun 26, 2013, at 4:52 PM, Fernando Gont
> wrote:
>
>> On 06/26/2013 12:56 PM, Mark ZZZ Smith wrote:
>>>
>>> One of the issues with conventional ICMP PTB based PMTUD is the
>>> default rate limi
ses.
Many implementers don't want to rely on a 100% ICMP-less PMTUD because
of the potentially-lng convergence time (i.e. time to discover the PMTU).
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076
at "we need to make sure we
understand the bigger picture"... because the I-D was brought back to
the wg for a low-level detail, and not for the "bigger picture".
Just me trying to make progress.
Cheers,
--
o be what the wg
is supporting?
This document has been suffering from unnecessary delays for almost a
year now.
It's not very encouraging for people to contribute opinions to this wg
if, when most people seem to be arguing one way, but you decide to go
another.
Cheers,
--
Fernando Go
July/August (1.5 months from now)
to ship the document? -- So far, all comments I've seen (at least 5)
have argued in favor of shipping the document... so it looks like
there's consensus on shipping...
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Finger
ssed, and that there's
general agreement to move the document forward.
So, procedurally-speaking, I don't understand the basis of stalling this
document.
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fing
ping?
On 06/12/2013 07:55 PM, Fernando Gont wrote:
> Folks,
>
> This latest revision addresses the feedback sent by Alissa Cooper.
>
> Should we progress this document now?
>
> Thanks!
> Fernando
>
>
>
>
> On 06/12/2013 07:45 PM, internet-dra...@iet
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
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
IETF IPv6 working
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
;
> 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
I
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
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
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
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
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 8FB1
s draft is a work item of the IPv6 Maintenance Working Group of the IETF.
>
> Title : A method for Generating Stable Privacy-Enhanced
> Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)
> Author(s) : Fernando Gont
> Filename
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
IETF IPv6 working group
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
f the existing headers. Use
> ICMPv6 Parameter Problem as a signal to switch back to the old
> fragmentation header.
mm.. not sure what you mean.
P.S.: Any thoughts regarding limiting the extension header chain to some
specific size?
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...
e destined to, and whether there
can be a legitimate use case for them or not (e.g., you might want to
allow fragments for clients, but drop them if they are destined to your
web server... in the same way that you might filter fragments to your
router, but not through your router).
Cheers,
--
Ferna
all chance of getting through the
> network, and that's much more guidance than we give today. And it
> gives hardware designers a target that seems to relate to reality.
FWIW, that's my take, as well.
Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
mmed through the that thread... but it seems unlreated to this
issue -- that thread seems to be about filtering RHT0, which has/had
known security issues such as being useful for amplification attacks.
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP
your network using something
for which there wasn't a legitimate use case (legitimate == such traffic
was needed by the task to be performed, and this was known as such to
the admin).
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C
e of the IPv6 header chain?
2) If so, which limit should we pick?
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
IET
packet. With an IPv6 minimum MTU of 1280 bytes, a limit of
XXX bytes for the entire header chain already allows for YYY % of overhead.
(for the first bullet, we could add an informative reference to Warren
et al's I-D).
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6n
some people are re-using old hardware cards
> they had hanging around does not mean everyone has to go along with it.
Agreed: You can always choose to "engineer" an un-deployable
protocol/mechanism and complain about the network.
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@s
em to be so unreliable already, that if you're to
implement an "extension", you better rely on something else. -- not that
I like it, but... me not liking it doesn't make the situation any better :-(
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fi
On 06/09/2013 06:36 PM, Ray Hunter wrote:
>> Fernando Gont <mailto:fg...@si6networks.com>
>> 9 June 2013 15:46
>> Ray,
>>
>> I'd say one should enforce a "each EH can be present at most once".
>>
>> ANd, me, I'd limit the EH
e IPv6 minimum MTU... so we'd be allowing
packets that are 100& overhead.
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
inful.
I guess having a L4-pointer would have helped quite a lot.
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
IETF IPv6 working grou
n such a document even before
this whole discussion came up). To some extent, including such whole
discussion here looks a bit side-tracking.
But I'd love to hear what you and others think about it.
Thanks!
Best regards,
In practice, it wouldn't make much sense, probably (most
of the packet containing overhead?).
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
imit the number of
instance of each extension header -- but that wouldn't probably fly here...
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
ode's
> stable IPv6 address," correct?
Yes. If you think it'd be better to phrase it that way, I can update the
text accordingly.
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
---
work item of the IPv6 Maintenance Working Group of the IETF.
>
> Title : A method for Generating Stable Privacy-Enhanced
> Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)
> Author(s) : Fernando Gont
> Filename: draft-ietf
dresses" are
> employed together with stable addresses such as those based on IEEE
> identifiers, implementation of the mechanism described in this
> document would mitigate address-scanning attacks and also mitigate
> some vectors for correlating host activities that are
#x27;t it a *requirement*
to do that, already?
>>> B.1.3 Worth any consideration of MIPv6 here?
>>
>> It has been years since I last checked MIPv6 (and when I did, I
>> mostly just skimmed through it). So... up to yo
Hi, Tim,
On 05/22/2013 10:50 AM, Tim Chown wrote:
>
> On 21 May 2013, at 03:00, Fernando Gont wrote:
>>
>> Additionally, I'd like to better understand the stability properties of
>> UUIDs (and add some text about it right after the text that you have
>> su
at this example is important, since the example is
> one where there's nothing the target node itself can do about it,
> which is non-obvious. Otherwise readers could be as confused as
> I was. So pointing it out adds significant clarity.
Ok. Will do.
Thanks!
Best regards,
hat got me sidetracked (including a car
accident -- although everything's fine now).
Thanks for checking!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
---
27;t it enough simply noting that the target node can be probed?
Getting into the specific details of the probe packet
(stimulus/response) seems like "over-specifying" things to me...
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B
using PRFs in novel ways to do specific things.
What I did was to apply Bellovin's RFC1948. So any IPR claim on
draft-ietf-6man-stable-addresses that predates RFC1948 and that's is not
Bellovin's is claiming credit for somebody else's work.
Thanks,
--
Fernando Gont
SI6 Ne
tacks, and what stable privacy addresses do
about them (analyzing this for every possible address generation
mechanism would be out of scope for this I-D, IMO).
Thanks!
Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9
your local router
>> (i.e., if I receive one of such messages, you're not there. If I don't, you
>> are).
>
> Ok, yes that one is interesting.
An attacker just needs one vector to be successful. And at the point
such vector is not under your control (as in this case),
).
* CGAs are IPR encumbered. draft-ietf-6man-stable-privacy-addresses are not.
* CGAs cannot be used in conjunction with RFC4941.
To be honest, the argument of "using CGAs instead of stable privacy"
sounds to me pretty much like "you don't need a hammer, because you can
use
27;s the right thing to do
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
IETF IPv6 working group mailing list
ipv6@ietf.org
Admi
node is in the same network for
> a long time or permanently.
Please add and elaborate on this in your I-D, because I don't follow the
relationship between bank accounts and IPv6 addresses.
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Finge
1 - 100 of 504 matches
Mail list logo
