Subject: RE: [tcpm] ICMP and TCP

From: "Bora Akyol" <[email-masked]>
Date: Fri, 19 May 2006 14:19:36 -0700

> -----Original Message-----
> From: Templin, Fred L [mailto:[email-masked]] 
> Sent: Friday, May 19, 2006 2:08 PM
> To: Bora Akyol; [email-masked]
> Subject: RE: [tcpm] ICMP and TCP
> 
> > This is why security of PMTU should be solved at the IP 
> layer, don't 
> > you think?
> 
> No; that would require the source system to have a security 
> association with every router on the path - unless you want 
> to ignore all "packet too bigs" that come from intermediate 
> nodes in which case you would black-hole.
> 

Only if you use IPSEC.

The point is that TCP IMHO is powerless to secure ICMP messages.
By making changes to TCP to declare ICMP errors as soft errors
depending on the state and ignoring some errors altogether,
we are trying to create a workaround for a problem with another layer
in the protocol stack.

This is all and well to solve a short term goal, but what is the long
term answer?

Thanks

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Fernando Gont <[email-masked]>
Date: Sat, 20 May 2006 02:19:00 -0300

>we are trying to create a workaround for a problem with another layer

Engineering, maybe?

>This is all and well to solve a short term goal, but what is the long

Well, you are probably getting into "architecture" issues.

You would end up asking other questions such as:
Shouldn't multihoming be a network layer thing, rather than a 
transport protocol thing?
Where should we really be doing congestion control?

etc.

Kindest regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Pekka Savola <[email-masked]>
Date: Sat, 20 May 2006 09:04:24 +0300 (EEST)

> we are trying to create a workaround for a problem with another layer

The other way to put this would be that we're creating a solution 
that's deployable today (heck, a lot of it has been deployed for over 
10 years) and brings by-default significant increase of security.

The other alternative is to either:

  1) put our head in the sand and get even farther disconnected from 
the way TCP has been implemented, or

  2) try to invent an overall big picture solution to this (I think 
IPsec was supposed to do this, but it hasn't been exactly succesful),
which very likely WON'T end up being used any time soon.

We need the practical, easy solutions to *existing* protocols.  "More 
architectural" alternatives are very good in paper, but should not 
preclude documenting the more direct approaches.

Remember that these two "ICMP and TCP" documents aren't even geared 
towards Standards Track at this point.

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