[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on current-practices-05

I've omitted parts of comments to which I have no more to say for one reason or another, 

On Mon, 17 Jul 2006, Merike Kaeo wrote:

Specific comments below..

Higher level
------------

==> 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.
==> 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?). 


substantial
-----------

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. 


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. 


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'. 


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." 


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.


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). 


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.


editorial
---------
Any of the specific attacks discussed further
  in this document will elaborate on attacks which are sourced by an
  "outsider" and are deliberate attacks.

==> "Any of the .." ?  "... attacks ... elaborate on attacks ..."?
A bit of rewording would help here.


Why?  Too many uses of the word 'attacks'?  Hmmmm......
"Any of the" seems to be suboptimal compared to "All the" (if that was intended".
Also 'attack' mentioned 3 times, and at least one of them should probably be something else ('threats'?). 

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings