Re: [OPSEC] minutes part 2

Hi Ran,

> On  16 Dec 2008, at 12:27, Vishwas Manral wrote:
> > Thanks for the information about insider attacks. I have 
> raised issues
> > with using IPsec ESP for OSPFv3 protection about 3 years back, as we
> > cannot block packets in all such cases (as the firewall may not know
> > of the contents inside the ESP packet).
> 
> Your claim above is not obvious.
> Please explain when/why you believe the claim above is true.

It is impossible for firewalls and intermediate routers to differentiate between encrypted ESP and ESP NULL packets by simply examining them because of the way ESP is defined. This poses problems for the firewalls since such packets (OSPFv3) cannot be filtered and identified. 

You could read either of the drafts for more details:

draft-ietf-ipsecme-traffic-visibility
draft-bhatia-ipsecme-esp-null-00.txt

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

If the intention is to only provide protection against passive attacks then you don't need cryptographic authentication - You can very well do with clear text passwords.

> >
> > This seems to contradict what you stated as the first point about
> > "First, let me observe that IGP attacks are all insider attacks."
> 
> Not at all.  This looks like an English language issue to me:
> 
> - All IGP attacks would have to be insider attacks,
>    because external packets are normally filtered anyway.
> - I am not aware of any IGP attacks ever occurring in the
>    deployed world.  There might be some, but I am not aware
>    of any published reports during the past ~20 years.
> - If someone has seen an actual active attack on any IGP,
>    that would be VERY interesting to learn more about.
> 
> > Well we do not have to wait for the first attack to act, we need to
> > react even before the attacks occur. You may have noted a 
> similar move
> > in all Security groups even though attacks themselves have 
> not occured
> > yet.

I agree. You don't need to wait for attacks to happen before you start exploring other options.

> 
> Network operators have a range of mechanisms available now in shipping
> routers.  Which mechanisms, if any, make sense to deploy is entirely
> up to their judgement -- based on their risk/threat model for their
> specific deployment.
> 
> > Also note we have to consider the havoc to the forwarded 
> traffic that
> > can be caused if the routing infrastructure is compromised. So the
> > effect of an attack is more than just attacking an end user site.
> 
> Again, there are a range of existing mechanisms that network operators
> can choose to use -- and there seem to be no reports of any IGP attack
> in the real world.

Then you don't need cryptographic authentication for IGPs. Cleartext should be good enough.

> 
> >> 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.
> > Agree partially. It is a goal but not the only goal of 
> cryptographic  
> > mechanisms.
> 
> You personally might have different goals for IGP authentication,
> but the various mechanisms extant (excepting RFC-2154) were only
> designed to protect against passive attacks (as described in 
> RFC-1704).

I find it strange that you find computing SHA computationally expensive (you stated this multiple times here on this list), while having no qualms on the overhead incurred when computing full digital signatures. Public Key Cryptography is *very* expensive and it drastically slows down the performance of the router. Then you have this problem of key distribution and somehow certifying the public key, etc.  

> 
> I have either authored or co-authored every one of those IGP 
> mechanisms
> (e.g. the OSPF MD5 mechanism is why I get the acknowledgement in the
> OSPF RFCs).  They protect against a limited set of issues.  The
> limitations are widely understood in the community.  For example,

.. which is why we're documenting them in draft-ietf-opsec-routing-protocols-crypto-issues-00.txt.

> at the BOF held at IETF/Dublin, the entire room appeared to understood
> from the beginning that the current mechanisms are very 
> limited.  I was
> quite clear in my comments during that BOF that the current mechanisms
> are limited.

Then why do you mind listing them out?

> 
> If one wants more, then the work that other folks have done with
> "Digital Signatures" (RFC-2154) seems like the right direction to go.
> That approach provides MUCH more comprehensive protections than
> any other current mechanisms.  (This is all a rehash of comments

.. at an additional cost that you seem to conveniently forget. Also note from my previous email on the list that there are still some holes in the digital signature scheme.

> I made during the KMART BOF at IETF/PHL, not all of which comments
> made it into the minutes.)
> 
> IS-IS and RIP likely would benefit from having equivalent 
> specifications
> developed; for OSPF, RFC-2154 already exists.

See my previous points.

Lets not talk about 2154 and concentrate on the two drafts in question:

draft-ietf-opsec-routing-protocols-crypto-issues-00.txt 
draft-bhatia-manral-igp-crypto-requirements-03.txt 

I know you are responding to the minutes posted on the list. However, since those are related to these drafts, I would urge you to read the above drafts and then comment specifically on the drafts. This imo would be more productive for the WG.

> 
> (I have no personal interest in developing such "Digital Signature"
> specifications for either IS-IS or RIP, but perhaps other folks here
> do.  I think it would be helpful to have the specifications completed
> and openly specified so that users who wanted something stronger
> could ask for something specific.)
> 
> 
> >> % 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.
> > IPsec with Manual Keying still states there can be no Replay  
> > protection.
> 
> RFC-2154 does not use IPsec.  So a comment about IPsec
> is orthogonal to the discussion.  Please go read RFC-2154.
> 

[ .. ]

> 
> Moving to HMAC-SHA1 does mean that the CPU on a router
> receiving a DOS attack via some IGP would be more severely
> impacted (because SHA1 is more computationally expensive
> than MD5).[2]

As I have already mentioned in my earlier mail, this assertion is without any foundation and is perhaps based on router implementations that you are aware of.

[ .. ]

> So one can see that there is no obvious net gain for users moving
> to HMAC-SHA for IGP authentication, relative to either HMAC-MD5
> or Keyed-MD5.  Moreover, there is increased impact on the router CPU
> (and hence the router control plane generally) of a prospective
> DOS attack on IGP packets if any form of SHA is used.[2]

Same as above.

Cheers, Manav

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