[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on current-practices-05
My replies embedded......
==> section 2.2 should *really* be merged with 2.3. It's almost
identical
except the terms. That should save 4 pages and reduce repetition
and text
duplication.
I had made the decision to leave separate but can merge if that is
really necessary.
As said, I'd strongly encourage merging myself, as the issues are
almost identical.
I'll merge and modify wording where there's some slight
differences........
==> some sections have the "confidentiality violations", "off-
line crypto attacks", etc. subsections while some do not. Some
are also 2.x.y.y subsections where others are 2.x.y. Should this
be consistent. Are these sections even necessary? At least in
some cases it seems as if the typical attacks don't fit well
under that kind of classification?
html formatting error for where subsections are not 2.x.y.z so
thanks for noticing that. I had a lot of comments earlier in this
work to include so I'd hate to take this out. Can you point to
some specific examples where the typical attack doesn't fit well?
For example, device physical access, SW upgrades and config
validation, possibly the sections where this wasn't included (2.7?
2.8?).
I'll look to modify wording where necessary. Filtering subsection
(2.8) and DoS (2.9) are a little bit different from the rest since
they overlap with previous sections but are important enough to
describe separately. So the 'attacks' were left out on purpose since
it would be somewhat redundant. But I'll add some wording.
However, if appropriate monitoring mechanisms are in place,
these attacks can be as easily detected and mitigated as with any
other attack source.
==> [these attacks] refers to insider attacks and unintentional
events. It's a bit of stretch to claim the equal amount of
detection for the former. Maybe add "typically" or some such here...
Not sure I agree. Let's say someone mistypes a routing
configuration. When a routing propagation error is detected you
go through same method to resolve issue and what's the difference
if it's sourced erroneously from your box vs someone else's?
Isn't detection and mitigation similar? Once you figure out where
error is coming from then you have to determine if box was
compromised or whether it was an honest mistake but that should be
traceable from logs and audit trails (if enough info is available).
Can you give me an example of where there is a big difference in
effort? Be happy to change text if I am missing a point here.....
What I mean that if an insider wants to attack the system,
depending on the access rights (s)he might use mechanisms which
make it difficult to trace information (e.g., a non-personal
account) or masquarade the changes somehow (e.g., make lots of
authorized changes at the same time so that without really careful
review of config diffs you wouldn't spot a thing, attack some parts
of the management server e.g. log collection, audit trails, the
password storage).
For naive insider attacks where a user just logs in and makes an
unauthorized change, yes -- the same procedures should help. But a
really resourceful attacker (who has more rights to the system, is
able to compromise management hosts, etc.) could make it
significantly harder to figure out what's going on -- hence my
suggestion to use 'typically' or some such.
OK, I see what you mean - will add 'typically' or some wording to
not make them seem as equal (although I think that an outside
attacker can be as resourceful depending on how much time they had to
figure out how to cover tracks.....it would be interesting to see if
someone has done a study on this.......comparing traceability of
insider vs outsider attacks......)
For privileged (i.e. enable) access, a second
authentication step needs to be completed.
==> this seems vendor-specific. Not all vendors have a
separation of ro/rw
access levels (for most purposes in any case), but are rather
role-based.
(Also in sect 2.1.3 though text there is more generic.)
Equipment that the ISPs use that I surveyed this is the
case.........perhaps all equipment should support this
functionality?!? Remember that this doc is supposed to support
capabilities documents and give a justification of why specific
capabilities should be supported.....
This cannot be true. AFAICT, there is no 'ena' in JunOS (only su
but that's for shell), which is used significantly by probably all
the respondents. Hence the survey results must be taken with a
grain of salt..
It is also debatable which is better: user-specific, restricted
authentication, or that you'd have a global enable-password which
would open the doors to do almost anything. Personally, I'd
probably pick the former (given that the users are already
controlled and authenticated) or in ultra-paranoid world something
in between: users would need to give personalized password (or some
such) to perform a restricted, personalized set of additional
commands. But this seems to be beyond the scope of current
practices, to be debated with the capabilities documents.
Sigh. I think this is a wording issue more than concept but I have
sent emails to a few of the people I surveyed to double-check and
make sure that I will have appropriate wording. I think if I had
said 'For greater privilege access, a second authentication step
needs to be completed' it would not look so cisco-specific and I was
trying to encompass even different role-based situations. But as I
said, I am double-checking with at least 6 ISPs right now just to
ensure correctness. Note that the survey was done by personally
interviewing and spending a few hours with the security people at
these ISPs so it wasn't just a paper survey with check marks and fill
in some detail. This effort was undertaken to try and generalize
what ISPs are doing but in some cases, the generalization is somewhat
difficult since the implementation can vary. I am somewhat
disconcerted by the statement that the results must be taken with a
grain of salt........that's unfortunate as I hope I am not wasting my
time?!?.....
2.2.1
For off-path active
attacks, the attack is generally limited to message insertion or
modification.
==> how could an off-path attacker perform message modification ?
(The same in section 2.3.1 and actually many others as well,
including
2.6.1-- maybe I have a different notion of "off-path"..)
Let's say an attacker causes traffic to be rerouted to him and
then he's basically a MIM....although technically 'off-path' since
he is not in the correct data path. Sure, grey area of on-path vs
off-path but I think this applies. Most attacks are combination
of attacks from how people try and classify them........
Section 1.3 definion said,
Thus, if an attack depends on being
able to receive data, off-path hosts must first subvert the
topology in order to place themselves on-path.
.., but I agree this is not 100% clear whether off-path attacker in
the text I quoted refers to off-path _before_ or after subverting
the topology. Unless further qualifiers are added to indicate the
need to reroute and become on-path, I think it would be clearer to
assume 'before'.
I'll add text to clarify...
One such example is at edge boxes
where you have up to 1000 T1's connecting into a router with an
OC-12
uplink. Some deployed devices experience a large performance
impact
with filtering which is unacceptable for passing customer traffic
through.
==> so why wouldn't uRPF be applied at the box at the other end
of this
OC-12 uplink then? The security perimeter would be drawn in a
different
place but this should work fine...
Something to ask the ISPs who were surveyed.......anyone on the
list reading this care to comment? All large ISPs I talked to did
not use MAc address filtering or authentication.
You probably mistyped above because the context was IP spoofing
filtering. Unless you hear more on this, I think it should be fair
to add to the sentence something like, "through, though ingress
filtering might be applicable at the devices connecting these
aggregation routers."
agreed....and remember that this will last call to include NANOG
list..... :) We want a complete sanity check......
2.5.4. Replay Attacks
For a replay attack to be successful, the routing control plane
traffic would need to first be captured either on-path or
diverted to
an attacker to later be replayed to the intended recipient.
==> most routing protocols have some way or another to protect
from replay
(I'm assuming this means replaying without modification, because
otherwise
this would be just insertion), so in the general case I doubt
this is very
useful..
But it can be done in some instances right? Or are you advocating
just getting rid of this paragraph?
[[ similar comment applies to 2.6.4. -- I don't see how you could
apply a
replay attack here in practical sense -- TFTP config download at
most but
because config isn't signed, modification is more lucrative...]]
Again, are you advocating I should just get rid of this paragraph
or reword?
I think it's useful to mention replay as a theoretical possibility,
but we should still mention that many protocols actually do have
replay protection mechanism. For example, in 2.5.4 add:
However, many protocols include replay protection mechanisms that
also need to be subverted if applicable.
OK
Note that validating
whether a legitimate peer has the authority to send the
contents of
the routing update is a difficult problem that needs yet to be
resolved.
==> this statement appears slightly misplaced (or redundant)
given that the
next paragraph discusses this very issue..
Redundancy in my mind is good....and I prefer to think of it as a
lead-in :) You feel strongly that it should not be there?
It's OK to put it there, but if it stays I think some rewording is
needed because it's not obvious from the wording whether it's lead-
in to the next paragraph or something else (which isn't mentioned).
OK
Consistency between these policies
varies greatly although there is a trend to start depending on AS-
PATH filters because they are much more manageable than the large
numbers of prefix filters that would need to be maintained.
==> the important distinction here is probably towards an end-
site vs peer
or another big ISP (even if a customer). There is no argument
that you
should prefix filter your end-site customers. Others are up to
debate..
==> the document should mention maximum-prefix-limiters,
typically applied
with peers or others where prefix lists cannot be applied. This
helps in
avoiding unintentional leaks, misconfig, etc.
Agreed. Can you offer any specific wording? I.e. a sentence or
two that would be appropriate?
For max prefix limits? For example,
Many operators define a maximum prefix limit per peer to prevent
misconfiguration (e.g., unintentional deaggregation) or overload
attacks. When the limit is exceeded, the session is either reset
or further updates are denied. Typically a lower warning threshold
is also configured.
OK
And again, thanks for thorough read since the intent is to accurately
depict what is done today in a clear manner.....
- merike