h in this document:" followed by a list that includes
route leakage (with a concise definition of what is meant by it in this
context). A similar statement in the Security Considerations section would also
be useful for the people who tend to skip introductions but still need
I have read this document and think it should be published as a standards-track
RFC. It is fairly complex, but I could not find places to reduce the complexity
without removing scenarios that seem reasonably likely to pop-up in real-world
transitions.
--Paul Hoffman
On Aug 24, 2011, at 2:45 PM, Joe Touch wrote:
> On 8/24/2011 1:27 PM, Paul Hoffman wrote:
>> On Aug 24, 2011, at 12:19 PM, Joe Touch wrote:
>>
>>> Is there ever a reason that this service should exist as a totally open and
>>> insecure port?
>>
>&
on the same port (other than performance of the
> connection establishment)?
Those aren't enough !?!?
--Paul Hoffman
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
ot;are pretty
much useless and add considerable churn and complexity with little return from
a practical attack surface perspective". The closest I see in my notes is
"Doesn't gain anything against attack where an attacker could just do a
withdraw".
--Paul Hoffman
_
Arrgh. My bad. (I read the intro, I read TCP-AO, and I skipped to the end of
the list.)
Never mind, what I want is already there.
--Paul Hoffman
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
011, at 10:42 AM, Joe Touch wrote:
> IMO, this last line should read:
>
> other forms of trusted security at or below TCP
That seems like a good addition.
--Paul Hoffman
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
other forms of trusted security in place.
Of course, we can also just ignore the fact that many users want to do this,
but being honest in the document might be better than pretending otherwise.
--Paul Hoffman
___
sidr mailing list
sidr@ietf.org
https
I have read the document and think it would be a useful standard. In specific,
wearing my very dusty vCard-supporter hat, the constrained profile for vCard
seems quite appropriate.
--Paul Hoffman
___
sidr mailing list
sidr@ietf.org
https
t; not clear.
>
> no. it means drawn from the same number space. i.e. if the nonce
> differs, the cache and the router mean very different things by serial
> value 42.
Right, but that's not what "commensurate" means. The common definition across
multiple dictionaries is "proportionate" or "of similar size", and that is
definitely *not* what you mean here. I don't even find your definition in my
math dictionary, and the math term "commensurable" is not applicable here.
--Paul Hoffman
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
on-trivial editorial issue: the draft uses "commensurate" in many places
that does not match any of the definitions I can find in my dictionaries. I
*think* that the draft means "the same", but that is not clear.
--Paul Hoffman
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
na-objects draft on the RFC Editor queue. :-)
Which IETF have you been participating in where that kind of speed seems even
remotely possible? :-(
--Paul Hoffman
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
And, just to close the loop: do the TLS libraries have the same limitations
that the SSH libraries do that prevent them from being used with kqueue/epoll?
If not, specifying TLS would then solve the problem here.
--Paul Hoffman
___
sidr mailing list
ensures data-integrity,
> privacy is not of concern;
>
TLS is exactly like SSH and IPsec in this case. It is easy to configure TLS to
be doing integrity-only. The overhead for encrypting, if you are doing so, is
extremely low.
--Paul Hoffman
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
work as well operationally while TCP-MD5 is still considered
safe. Saying "MUST implement SSH" is tantamount to saying "many systems will
run unprotected", which might be acceptable until TCP-AO is deployed. However,
using TCP-MD5, but only until TCP-AO is deployed, seems lik
n that the
router MAY then issue a serial query earlier than it otherwise might.
This is analogous to DNS NOTIFY in [RFC1996]. The cache SHOULD rate
limit Serial Notifies to no more frequently than one per minute.
The first two indicates "MUST",
to be polling
anyway. I don't think that "maybe" makes sense at all, but could be convinced
otherwise.
--Paul Hoffman
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
aid that, I hope router implementers of this protocol are
being robust in checking the lengths in this PDU; I can already see ways to
craft malicious versions of this PDU that might trigger a buffer overflow...)
One can say a lot in 200 octets, even of UTF8.
--Paul Hoffman
__
semi-magic 256
octets for the current version of the protocol and yet gives bloviators such as
myself plenty of room in our error messages.
--Paul Hoffman
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
19 matches
Mail list logo
