expansion of TCPM WG (TCP Maintenance
Working Group).
Fixed!
Please let me know if the above address your comments
Thanks so much!
Kind regards,
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9
At 07:04 p.m. 18/11/2008, Nicholas Weaver wrote:
I would bet (but have no evidence) that the visa problem is almost
specifically a chinese issue.
It is NOT a chinese issue. I have got my USA visa, but it IS an issue
to get it.
Fernando Gont (from Argentina)
--
Fernando Gont
e-mail: [EMAIL
ts without having to add text back to the I-D.
Kind regards,
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
o ICMP soft errors.
>
> I have not incorporated this change. But please let me know if you
> feel strongly about it.
I think the old wording seriously overstates the scope of the draft, but
this is an editorial problem, not a technical one. I would still prefer
to see this changed.
ns to mailing-lists
*and* whether they actually get to post to the mailing-lists?
Or do you count as "participants" those that write documents and/or send
feedback about documents?
etc..
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
, I couldn't fully
understand what the guy at the mike was saying, either because of
low-volume, background noise, or a strong accent I wasn't used to.
Cheers,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
sentence of the abstract be changed to "This
> document deprecates such ICMPv4 message types and annotates the
> corresponding IANA registry entries." and that corresponding changes
> be made elsewhere in the draft where "clean up" is used.
I have no problem with a
mic fragments)
that we're improving.
I'm not sure what kind of document you have in mind... but my personal
experience says that being able to tackle isolated problems separately
(rather than work on a large document that tries to address a plethora
of issues) is (by far) more doable.
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
us TCPM concerns about these techniques.
We can remove "and [RFC5927]" or change it to "...Section 5.2 of
[RFC4443] and documented in [RFC5927]"
Thoughts?
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
aft diff too at
tools.ietf.org. When needed/appropriate, I've posted a summary of major
changes to the relevant mailing-list.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
ated
> from the network.
Could you please elaborate?
> The title of the draft is "Security Implications of IPv6 on IPv4
> Networks". The Abstract mentions "IPv4-only" networks. The
> Introduction Section mentions "networks that are assumed to be
> IPv4-only".
Please see the quotes when we say "'IPv4-only' networks" -- in practice,
there's no such a thing, and you should think v6 security even if you
think/want to run an IPv4-only network.
> I don't understand what this draft is about.
This one I cannot do much about. :-)
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
nt is saying.
> We shouldn't imply that not having an IPv6 plan and blocking all IPv6
> by default is a sound strategy.
It's not, and I don't think we're implying that. However, I'd note that
some people are in the position of blocking traffic, or not doing
anything
tions.
Welcome to the real world: That cat has been out of the box for years
(no matter whether you consider that a problem, or a feature).
FWIW, my TP-LINK router does that, even if I don't want it to.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
to allow such
connectivity reduces the potential problem (at the end of the day, this
is kind of the whitelisting approach that has been applied to the
general case by content providers -- with the caveat that in this case
you positively know that such connectivity is not present).
Thanks,
On 04/02/2013 10:25 PM, Ted Lemon wrote:
> On Apr 2, 2013, at 7:30 PM, Fernando Gont wrote:
>>> I agree with the last sentence. Happy Eyeballs is about the HTTP.
>>> There are other applications protocols too. :-)
>>
>> Happy eyeballs is about HTTP. But par
that sentence.
Would that be okay with you? -- If not, please do let me know, so that
we can try to find a way forward that keeps everyone happy.
Thanks so much!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
address it, please resend/ping me (most likely
I tried but failed, the feedback slipped by, or whatever... )
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
oduces a bit string larger than 64 bits, and
you say nothing about how you grab the IID, then the algorithm is
underspecified.
The easier it is for a developer to go through this document and come up
with an implementation, the better. The more the open questions, the worse.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
A compromise might be to add a *parenthetical* note such as:
"The current IPv6 Addressing architecture defines Interface-Identifiers
to be 64 bits long, hence the low-order 64-bits of F() are employed for
the Interface-ID. Were the IPv6 Addressing Architecture updated to allow
any arbitrary le
orithm for generating Interface Identifiers."
>
> If the implementation does not provide the means for the administrator
> to enable or disable the use of the algorithm, does it conform to this
> specification?
It'd be "conditionally-compliant", but not fully-compli
On 04/22/2013 03:39 PM, SM wrote:
> At 12:40 22-04-2013, Fernando Gont wrote:
>> PLease see the Appendix.
>
> I read that. I was confused by the short title (Stable Privacy
> Addresses) at first. I didn't see much discussion in the draft about
> privacy considerations.
faces, or enabling multi-homed hosts.
FWIW, constant addreses when swapping interfaces is not really a goal f
tis dcument, but rather a byproduct of it.
> And I would
> observe that the DAD problem cannot be solved ina reliable way.
Could you please elaborate?
Thanks!
Best regards,
--
Fernan
rally been very influenced by the input of a number of
participants... anyone who has ever sent me feedback on a document I've
authored/co-authored knows I do my best to address all feedback, no
matter whether that implies re-writing large portions of the document in
question.)
Make the spec as cl
or
how you store addresses in memory if you do store them).
I see the algorithm in this document as giving more room for tradeoffs
to developers than RFC4941, and the same room for tradeoffs as e.g. RFC6528.
Based on the above, me, I don't find the idea of re-writing the I-D
compelling -- particu
ces: RFC1948 is obsoleted by 6528. Is there a reason to
> reference the obsolete version?
Yes: RFC1948 is only referenced in the Acks section, where I note that
this document was inspired by Bellovin's work on RFC1948. While RFC6528
obsoletes RFC1948, the algorithm in that RFC is the same as that in RFC1948.
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Acks section, where I note
>> that this document was inspired by Bellovin's work on RFC1948.
>> While RFC6528 obsoletes RFC1948, the algorithm in that RFC is the
>> same as that in RFC1948.
>
> So 6528 equally illustrates Steve Bellovin's work, and is also more
> current, right?
Yes. But I'm a co-author of RFC 6528 -- so it'd be a bit arrogant (and
incorrect) to say that I was inspired by RFC 6528 :-) -- I was inspired
by Bellovin, rather than myself. :-)
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
addresses.
You you do not include some sort of "Interface ID", then, when two
interfaces are employed to connect to the same network, you are
guaranteed to get a collision...
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
using
> "some of the privacy concerns" in place of "most of the privacy
> concerns" in the two sections above.
Is there any other one left to be mitigated other than the one I
mentioned above?
>
> Nit:
>
> This link in the [Broersma] reference is broken:
ss such as rtadvd and others...)
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
On 05/27/2013 07:31 AM, Juliao Braga wrote:
> According to the news published for a long time in Brazilian newspapers
> and magazines, Buenos Aires (a wonderful place!) would not be
> recommended.
Recommended for what? And on what basis?
Cheers,
--
Fernando Gont
e-mail: ferna...@go
eople this way. Particularly
without any concrete data.
Note: I'm not not even touching the issue of whether having a meeting in
Buenos Aires is a great idea or not.. but just trying to keep the
discussion objective.
Un abrazo,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
inal currency. But I could double-check if
interested.
That said, man shops accept dollars and euros (not pounds, though :-( ).
So I guess that for the most part you could just have some small amount
of money in pesos (mostly to pay cabs, I'd say), and move around the
city using your credit c
tary to comment:
>
> "...But who should tell us about the true cenary would be our
> Argentine friends."
>
> Regards,
>
> Julião
> Em 28/05/2013 10:36, Fernando Gont escreveu:
>> On 05/27/2013 07:31 AM, Juliao Braga wrote:
>>> According to the ne
sed on what has been
"heard", "rumors", or what some idiot posted on a blog pollutes and
biases the discussion unfairly and inappropriately.
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
g
> overhead, indirect routing, etc. As such, this is an ideal number;
> the only way to achieve anything close to it is to have a private jet
> (with exceptional range).
Could you please elaborate a bit more on the meaning of the second column?
Thanks!
--
Fernando Gont
SI6 Networks
e-
han anyone else.
And they generally also keep the spirit of "open" more than anyone else.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
ould attend, whether they would have stuff to
present, etc. So I've set up a very short on-line survey to help us
plan for the meeting.
If you're interested, please take 5 minutes to complete the survey at:
<https://www.surveymonkey.com/s/FFL386K>
Thanks!
Best regards,
- --
Fernando
e dynamic selection of server ports and is
> | unrelated to ephemeral port selection, although this interpretation
> | has been promoted in the past.
Your suggested change makes sense to me. But as with the previous one,
I'd like to hear what Lars thinks about this one.
> (5) General
>
> A few editorial nits will be reported to the authors off-list ASAP.
Looking forward to them!
Thanks!
Kind regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
n and
Alfred Hoenes) who provided very thorough reviews that had a very
positive impact on the resulting documents.
Thanks again,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9
t funding
for attending meetings.
Just my two cents
Thanks!
Kind regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Ietf mailing list
Ietf@ietf.
ance (e.g., you need to schedule an
appointment, whereas for the canadian visa you need not).
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
d TTL (60). However, most implementations use different values
for the TTL (either 255 or a power of of 2, such as 64 or 128). This,
together with the fact that the TTL is assumed to be a hop limit (rather
than a time count) might leave some room for using a different upper
limit for the RTO (and
of my bank
account, etc.
Regarding the LOI itself, they usually accept LOIs in electronic form...
so I guess this is probably the case for the Chinese visa, too.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 9
because they used false
information to get their visas (said they had never live in the US
illegally, when they actually had).
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
entally different from IPv4 as it is deployed to day.
As ironic as it may sound, some people are actually *concerned* about
this. (no, not *me*)
> IPv6 also make IPsec mandatory, which seems a significant change over
> IPv4, too.
As noted by Fred, this is mostly "words on pap
ed' when in
> fact they are merely repeating an ideological view of security that
> has negligible support outside the IETF. That is a really bad way to
> approach security.
>
> There is more to security than throwing cryptography at packets.
Agreed. The work that we have done
uch they should charge you for e.g. a taxi
from the airport to the center of the city is usually valuable
information, too. It wouldn't be surprised if the taxi driver tried to
charge you more than he should if he realized you have no idea of how
much things cost there (this could easil
Phillip Hallam-Baker wrote:
> At the time email was a special case because it was the *only* application.
As far as I recall *reading* (I wasn't around at the time :-) ) email
was a couple of FTP commands? -- I seem to recall John Day writing about
this in his book..
Thanks,
--
Fernand
is Summer
time. ;-)
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
That's my experience with getting Canadian visas (I have got four or
five), from Buenos Aires (Argentina), being an Argentinian citizen.
Europe is much better in this respect. For instance, they don't require
visas for many latin-american countries (including Argentina).
Thanks,
--
Fern
> 5. Add a informative section discussing the pros/cons of IP-level
> intermediaries altering the URG bit.
> 6. Add a normative section which states that IP-level intermediaries
> SHOULD NOT alter the URG bit.
I don't think that tcpm is going to get consensus on "pros" of
for that reason)
Applications that are processing "urgent data" as "out of band" data
area already violating the specs -- hence the "MUST".
>>> 5. Add a informative section discussing the pros/cons of IP-level
>>> intermediaries altering the
gent
data" (as a result of ambiguities in RFC 793), and this never changed.
-- one might even argue that since there's no way of notifying the other
end how you're interpreting the UP, trying to change this would actually
break the current working code.
Thanks!
Kind regards,
--
Fe
irstly, the host might not implement
PMTUD, and hence setting the DF bit on its behalf could possibly cause
interoperability problems. Secondly, some hosts clear the DF bit if the
advertised MTU in an ICMP "frag needed" is below some specified
threshols. This RFC2402-behavior could cause proble
include point of attachment addresses in the
app protocol break in the presence of NATs, one should probably ask
whether the NAT is breaking the app, or whether the NAT is making it
clear that the app was actually already broken.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com
particular processes at particular hosts. Some might see this as a
> deficiency in the Internet
> Architecture, but that's the best that we have to work with for now.
If anything, the fact that "this is is the only way that the Internet
Architecture defines..." doesn't ma
NATs for broken application
designs, and that you should not assess reasonable-ness based on
existing (and questionable) application designs.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Sorry, I couldn't parse this paragraph. Could you clarify this one?
Thanks!
Kind regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Ietf mailing list
after the fact...
Sorry, but I don't follow. If the problem with widespread deployment of
IPsec was NAT traversal, why didn't we see widespread IPsec deployment
(for the general case) e.g. once RFC 3948 was published?
And: Do you expect IPsec deplyment to increase dramatically as IPv6 g
umes "improved security"
> In the scope of things, wh does having one of out of the many needed
> tools make IPv6 different than IPv4, especially given that the
> indicated tool is present in both IPv4 and IPv6 implementations?
>
> Scratch-a-my-head. I don't see
ings
get uglier with CGNs.
Anyway: since we will be running both IPv4 and IPv6 for lots of years,
the complexity of IPv6 adds to that of IPv4.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
__
so that
it's secure, and then assume that if your IP address is authorized, the
user at that IP address is authorized to print".
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
ent specs are concerned,
the "accepted window" is half the timestamps space: i.e., you need to
forge, at most, two different timestamps value. It also mentions that
timestamps may be easily predictable. However, this does not need to be
the case (see e.g., draft-gont-timestamps-generation)
acks (there are many other
vectors). If you want an alternative "published" reference, here it is:
http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf
However, it's up to the authors to include this or other references -- I
jus
On 02/02/2011 10:08 p.m., Joe Touch wrote:
> On 2/2/2011 5:04 PM, Fernando Gont wrote:
> ...
>>> At the least, it's worth noting that geolocation is already broken by
>>> tunnels, and that IP addressing does not ensure geographic proximity
>>> before attribu
On 02/02/2011 10:24 p.m., Fernando Gont wrote:
>> On 2/2/2011 5:04 PM, Fernando Gont wrote:
>> ...
>>>> At the least, it's worth noting that geolocation is already broken by
>>>> tunnels, and that IP addressing does not ensure geographic proximity
>>
s not considered in the IP design, is
irrelevant. As noted, IP wasn't meant for production, either.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
parsing this sentence.
* Section 11, page 12:
A client can use the ALGS command to request the ALG's status and to
enable and disable EPSV to PASV and, if implemented, EPRT to PORT
translation.
Please rephrase to "...disable EPSV to PASV translation and, if
implemented, EPRT to
-to-end connectivity" as
"gone". -- among other reasons, because it would require a change of
mindset. I'm more of the idea that people will replicate the
architecture of their IPv4 networks with IPv6, in which end-systems are
not reachable from the public Internet.
Thanks!
--
Wasn't the simple/advanced security RFCs produced by v6ops aimed at
typical home devices?
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Ietf mailing l
PNP
> like functionality for nodes to talk to the firewall(s).
I think this deserves a problem statement that clearly describes what we
expect to be able to do (but currently can't), etc. And, if this is
meant to be v6-only, state why v4 is excluded -- unless we're happy to
have people c
On 06/30/2011 12:56 AM, Masataka Ohta wrote:
> Fernando Gont wrote:
>
>> I personally consider this property of "end-to-end connectivity" as
>> "gone".
>
> How do you think about P2P applications?
I think about applications that would benefit from
our network -- i.e., "default deny")
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
IPv6), then that's fine... but not what I read from this
discussion and the proposed charter.
Thoughts?
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
__
k
>
>
>
> On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote:
>
>> On Thu, 30 Jun 2011, Fernando Gont wrote:
>>
>>> My point was that, except for the mechanism for PD, I don't see a
>>> substantial difference here that would e.g. prevent th
network to support some v6
feature for the network to work, such that our existing v4-only devices
can co-exist in whatever v6 home-network architecture we envision).
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076
IPv4 to be gone? (including "gone" from
home and enterprise networks)
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Ietf mailing list
Ietf@
ents considerations", instead?
* Section 7.3, page 22:
> If the number of fragments is high enough, the memory of the host
> could be exhausted.
s/high/large/ ?
* Section 7.3, page 22:
> BIN implementations MUST implement proper protection against such
> attacks, for instance
resulting IETF I-D is entitled "Security Assessment of the Transmission
Control Protocol (TCP)" (draft-gont-tcp-security-00.txt) and is
available at: http://tools.ietf.org/id/draft-gont-tcp-security-00.txt
Any comments will be more than welcome.
Thanks!
Kind regards,
- --
Fernando Gont
e-mai
;t made a difference". After all,
they had already implemented the stuff discussed in the document (and so had
others), so they really didn't have much of a reason to get involved in the
process.
I'd be glad to discuss a plan to pursue this work within the IETF.
Th
liency.
Thanks!
Kind regards,
Fernando Gont
Original Message
Subject: draft-gont-tcp-security
Date: Mon, 13 Apr 2009 09:19:43 -0500
From: Eddy, Wesley M. (GRC-RCN0)[Verizon]
To: t...@ietf.org
CC: Fernando Gont , Joe Abley
,Joel Jaeggli ,
"rbon...@juniper.net&quo
r attack, that is an OPSEC issue.
Yeah... problems with deploying it in the current Internet
If tcpm agreed that opsec will be a better venue for this document, I'll
be glad to pursue this effort there. At this point, tcpm and opsec are
two possible options, with no preference for any of the two.
K
hen
> complaining that nonsecure TCP is being attacked.
Joe, we're talkng about a simple web server being taken down because of
a SYN flood, a FIN-WAIT-2 flood, or the like. Even the most stupid web
server should survive these types of attacks.
Kind regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
CP basedon the document published by UK CPNI. Yet we're
still debating whether to ignore it or not maybe so that we can
publish an RFC in the future tagging those implementations as
non-compliant... or maybe to allow tcp vulnerabilities to be
"rediscovered" every few years.
Thanks!
K
yes, it could have been
worse, some might argue).
Thanks!
Kind regards,
Fernando Gont
The IESG wrote:
> The IESG has received a request from the TCP Maintenance and Minor
> Extensions WG (tcpm) to consider the following document:
>
> - 'Improving TCP's Robustness to Blind
objective as possible. At least for the ip-security counterpart, I
recall asking you to have a look at it before publication, even when I
knew that you'd most likely disagree with large parts of the document.
This project is already done but nevertheless I'm still spending
some cycles to
to find any implementation that is
fully-compliant with the RFCs, and let me know if you find any.
The lack of advice on all these issues has put vendors in a position in
which they have to figure out that advice by themselves. Sometimes they
got to the right answers, sometimes not.
Have a look at the vulnerability advisories referenced in the I-D: the
same errors are committed over and over again.
draft-gont-tcp-security is an effort to help the vendor/developer
community in that area.
P.S.: My apologizes for the possible politically-incorrect comments. But
this is the best trade-off I have been able to get between being
politically-correct and being honest.
Kind regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ch I am the author of draft-gont-tcp-security.
P.S.: The only reason for which my name is not in the cover page is
simply that that is not the format with which CPNI are published. But I
thought that my authorship of the CPNI document was implicit.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com
t seems clear to me that
> the vendor community is looking for guidance here, and I do believe the
> IETF should give it.
This is the reason for which the output of the CPNI project was
submitted as an IETF I-D.
Kind regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
P
nother attack vector which may be easier
> > to exploit. We discuss it in Section 16.2 of
> > draft-gont-tcp-security and the CPNI doc, along with advice.
> > IMO, this vector should be mentioned, too.
>
> This again is an attack which relies on the IP functionalit
--
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---
___
tcpm mailing list
t...@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--
Fernando Gont
e-mail: ferna...@gont.
the top of the next page.
I'm sure the RFC-Editor will take care of this.
P.S.: (All my "done", "fixed", etc., are subject to the documents
shepard's agreement ;-) )
Thanks!
Best regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Finge
On 01/05/2012 11:48 AM, Dave CROCKER wrote:
> If protocol corresponds with program or algorithm, then what is the
> communications term that corresponds to process?
"Protocol Machine". or "Protocol Instance".
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.a
also want to check this:
<http://www.schneier.com/blog/archives/2012/01/british_tourist.html>
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
Ietf mailing
;memoryand replaces existing "
* Section 4:
addresses (and in many cases becomes unable to perform maintenance of
existing entries in the neighbor cache, and unable to answer Neighbor
Solicitation).
s/Solicitation/Solicitations/
* Section 7.2:
s/Neighbour/Neighbor/
Thanks,
--
Fernando
ase in which the same person must be in two meetings
that overlap? (e.g., I've *presented* at overlapping meeting) What
should they do in that that case? Sign all the corresponding blue
sheets? Sign none?
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
he tables in front of the
registration desk about his (missing) badge, and told him next day he
wouldn't be allowed in without a badge.
And this folk ended up leaving the meeting area.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5
necessarily the case.
As noted above, I will go through the proposed IESG statement in detail
and comment. However, even if what's being proposed is not seen as the
proper way forward, there's still a problem (specs maintenance) that
needs to be addressed somehow.
Thanks,
--
Fernando Gont
t being
rpesented by some folks at the beginning of one meeting, and some other
doc being presented at the end of some other meeting?).
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
gt; architecture", but rather the endpoint name format supported by that option
> is totally general, allowing any endpoint name format to be used.
Please let me know if you have any suggestions on how to tweak the text
to improve this.
Thanks!
Best regards,
--
Fernando Gont
e-mail: fe
1 - 100 of 106 matches
Mail list logo
