Re: [OPSEC] minutes part 2

Hi Ran,

I was away and could not respond earlier.

> First, let me observe that IGP attacks are all insider attacks.
> Sites routinely block IGP packets from entering from outside
> their administrative domain.  (This would be a sensible thing
> for OPsec to recommend if it hasn't already done so.)
> Similarly, ISPs normally block IGP packets from arriving
> on customer-facing interfaces or other exterior interfaces.

You btw cannot do this if IPSec is deployed. Look at the discussions in IPSECME for more details.

> 
> Second, prospective attackers are both smart and lazy.  They
> are not likely to use a computationally expensive attack
> vector (e.g. something cryptographic) when a simpler/easier
> attack (e.g. DoS on the router CPU) exists.

Would you like to elaborate on what constitutes a simpler/easier attack? Most of the vendors now provide protection against the simple/easy attacks that you are probably alluding to.

> 
> Third, I am not aware of any active attacks on any deployed
> IGP.  I've worked at more than one network operator in the
> past, and for multiple equipment suppliers.  I've never heard
> of even one.  If active attacks were widespread or common,
> then they would have received much more reporting in the
> trade press (as different from the zero reports that I've
> seen over the past ~20 years).

I agree. However, you might understand that operators may not go out of their way to make this public.

Irrespective of the above, the OPSEC WG doc draft-ietf-opsec-routing-protocols-crypto-issues-00 makes no such claims. It just lists down the possible holes that exist despite using cryptographic authentication mechanisms in the IGPs.

This is not the first time such a discussion (spoofing in routing) has been brought about. It has been discussed several times in the RPSEC WG, individual routing WGs, KMART BOF, etc. and its for the first time that I am hearing somebody assert that security is not an issue in routing protocols.

> 
> Fourth, the *only* goal of the various cryptographic IGP
> authentication mechanisms (excepting: RFC-2154) always
> has been to remove only the "passive attack" risks described
> long ago in RFC-1704.  Such passive attacks are trivially
> easy to mount, even easier than a simple DOS attack, which
> is why they are sensible to protect against.

Again, would you mind expounding on this?

> 
> Fifth, the existing cryptographic authentication mechanisms
> are not really widely deployed operationally.  Many enterprise

Really? We have several customers who use cryptographic authentication mechanisms. If you doubt this you could post a survey on nanog.

> users don't enable any form of authentication.  Some enable
> clear-text passwords; relatively few bother to enable
> cryptographic authentication.  Among ISPs, security mechanisms
> are more widely deployed, but even in that community the
> existing cryptographic authentication mechanisms appear not
> to be widely used today.  This is not because operators/users
> are silly or uninformed.  Instead, this is because they are
> performing sensible risk/threat analyses and deploying what
> actually makes sense for their operational environments.
> 
> % OSPF cryptographic sequence number spoofing or replay
> 
>  From a technical perspective, these are solved problems.
> Please see RFC-2154.  Note that the absence of commercial
> implementations of RFC-2154 reflects the total absence
> of user/operator concern about either of these issues,
> along with user/operator concern about the complexity
> of a digital signature approach.

I have not yet read the entire thread but you seem to offer 2154 as a panacea to all security issues, which imo is without any basis and foundation.

A quick glance through 2154 reveals some issues and I am sure there are a LOT of other issues that could be present. Mutable fields are not covered by the digital signatures and can thus be exploited. 2154 mandates globally synchornized clocks between all trusted entities, something that is definitely not easy to achive given that clock synchronization could itself be exploited.

Then you must also appreciate that there hasn't been any effort employed to study weakness in 2154 as this isnt deployed. So, lets leave this out of draft-ietf-opsec-routing-protocols-crypto-issues-00.

> vulnerabilities in either Keyed-MD5 or HMAC-MD5 as used by
> IETF routing protocols.  By contrast, moving to SHA will
> significantly increase a router's vulnerability to DOS attacks,

I think this is a very irresponsible statement to make since your comments seem to be based on specific router implementations. A good implementation can do this without exposing the CPU for DOS attacks.

> while providing negligible decrease in risk.  (Also see
> the comments 3 paragraphs down about SHA's own issues.)
> 
> There is only one known user with any interest in SHA
> authentication for routing protocols.  They have said
> that the only reason for that interest is "policy compliance".
> Even they have not yet indicated that SHA support is required
> of their equipment suppliers.
> 
> Further, there are no known shipping implementations of
> SHA authentication for any IETF-specified IGP.  (I don't
> know of any that are even "in progress".)

I know of atleast two vendors who are working on this. Contact me offline if you want me to connect you to the people in charge of this work.

> 
> % Keys shared across the broadcast domain,
> % need to move to a stronger key identifier.
> 
> 1.  All IGPs multicast/broadcast their update packets,
>   so sharing a key across that same multicast/broadcast
>   domain is not a silly approach.

Nobody is contesting this. However, this has some obvious issues, and we should see if we can solve this.

> 2.  Adding a Key-ID does not actually increase the
>   security of anything.  It can make it slightly simpler

You probably misunderstood the advantages incurred by using a Key ID. 

>   for an implementation to locate the correct Security
>   Association to use in attempting to authenticate a
>   received packet, however the most widely deployed

I repeat, you are again, referring to the implementation that you are aware of. I would urge you not to make such sweeping statements about routing implementations.

>   implementations *ignore* the Key-ID and instead just
>   try all configured and valid SAs on the router.

See above. BTW, one gain of a Key ID is to avoid the very behavior that you have described above.

> 
> % For OSPFv3 relies on ipsec, because manual key sequence number,
> % replay protection cannot be used.
> 
> See comment up top with reference to RFC-2154.

See comment on top.

> 
> % IS-IS MD5 but no sequence number not notion of keyid
> % for pdu key must be validated.
> 
> See previous comments.
> 
> Separately, IS-IS is carried directly over the link-layer,
> so off-link attacks are automatically precluded.  This means
> that the only possible threat model is an on-link insider.
> There are simpler/easier attacks (e.g. DOS) on the routing
> infrastructure.  So adding a sequence number doesn't really matter.
> Again, the KeyID is merely an implementer convenience, rather than
> some form of risk reduction.

We don't even recommend adding sequence number to IS-IS. However, it is just brought to the reader's notice.

If there was any intent of doing so then we would have added this in draft-ietf-isis-hmac-sha-07.txt

> % ripv2, no authentication of ip or udp headers.  can change
> % source address and receiver will still think it's a valid
> % neighbor
> 
> If MD5 authentication is enabled, packets can't be forged.

Yes, but that doesn't preclude the possibility of an attack. I remember sending you an email about this some time back.

Please read section 6 of draft-ietf-opsec-routing-protocols-crypto-issues-00.txt

> % Second draft, minimum cryptographic requirements.  the fact is
> % cryptographic algorithms continue to be attacked.  we need to
> % keep track of this.  the idea of this document is to keep
> % modifying it but to track the minimum requirements for  
> interoperability
> 
> I see this document as largely valueless.  Most users/operators
> aren't enabling any form of cryptographic authentication today,
> because their risk/threat environment makes that not sensible
> for their operational domain.

Again, a very wrong assertion.

> I am not aware of *any* known attacks on any deployed IGP with
> any form of cryptographic authentication configured.  If someone
> has actually seen such himself/herself, please provide the details
> here as that would be significant news.

I agree. However, this doesn't mean that we should not highlight the issues that exist in the current crypto protection mechanisms. 

Please look at RFC 4593. Do you think all the threats mentioned there have actually been seen in the wild?

Cheers, Manav
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec