Re: [tcpm] TCP-AO and ICMP attacks (was Re: comments on draft-ietf-tcpm-icmp-attacks-05)

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Joe Touch wrote:
> 
>>>> 5) (general) Section 5.1, last paragraph, it
>>>> seems like we should be mentioning TCP-AO as
>>>> well here, though I don't think it changes any
>>>> part of the claim.
>>> Agreed. Maybe this is also an indication that TCP-AO *should* change
>>> something in this respect!
>> TCP-AO already addresses ICMP attacks in the security considerations
>> section, and requires there to be a way to disable reaction to ICMPs.
>> Like IPsec, though, we don't make a-priori assessments as to whether
>> ICMPs should be blocked or not on connections on which TCP-AO (or IPsec)
>> is used.
> 
> What's the point of enabling TCP-AO, if you are not going to disable (or
> hard errors -> soft errors)?

See the text in RFC4301.

> I think that for the sake of the "principle of least surprise", ICMP
> hard errors SHOULD NOT abort connections for which TCP AO has been enabled.

Please explain why you think that TCP-AO needs more strict advice in
this regard than IPsec.

> What to do with "frag needed" might vary. Although one could argue that
> you SHOULD implement PLPMTUD.

- ---

We could add that TCP-AO, like IPsec (text copied from 4301):

   ...A compliant TCP-AO
   implementation MUST permit a local administrator to configure an
   IPsec implementation to accept or reject unauthenticated ICMP
   traffic.  This control MUST be at the granularity of ICMP type and
   MAY be at the granularity of ICMP type and code.  Additionally, an
   implementation SHOULD incorporate mechanisms and parameters for
   dealing with such traffic.  For example, there could be the ability
   to establish a minimum PMTU for traffic (on a per destination basis),
   to prevent receipt of an unauthenticated ICMP from setting the PMTU
   to a trivial size.

- ---

We can add a discussion of PLPMTUD, but rfc4821 doesn't have any
particular recommendations of implementation. We would need to be
careful to not tie TCP-AO to PLPMTUD in a way that impedes TCP-AO
deployment.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko3pVAACgkQE5f5cImnZruIhwCfccxoolqykof8xWtZ2Ud9cIZM
YB0AoMZ/1jeTrmKxvo2UPoy8KlGGmX0b
=Ermg
-----END PGP SIGNATURE-----