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

Re: ESP revisions straw poll

In message <199705162244.SAA01135@relay.rv.tis.com>, Charles Lynn writes:
>   It is my understanding that consensus includes more than implementers
>   who were able to make it to an IETF meeting.  It includes the whole
>   working group, whether or not they were able to get to a face to face
>   meeting.

It has also been the IETF "policy" that decisions are made by running
code and rough consensus. I believe that a very large percentage of
the implementors was at the IETF, and the majority of messages on this
list has been against encryptionless ESP. Including yours, that makes
3 messages in favour of e-ESP (Steve, Hillary and you); i've seen
many more against. I believe the matter has been discussed for a while
and the WG has indeed decided against e-ESP. Let's not talk about this
for so long that people will (again) walk away in disgust.

>   I am willing to leave the "try to protect the outer header" AH
>   functionality for the community that thinks it is useful, if others
>   are willing to provide a mechanism that allows another community to
>   protect bodies without concern for headers.

You can do tunneling (IP in IP), with the inner packet being AH
protected, ie: [IP][IP][AH][whatever]

But more importantly, IPsec is a network layer protocol. It gives some
assurances to the application. If the application cannot live with
those, it should certainly use some higher layer security protocol
(such as TLS). Trying to put in IPsec all the functionality of all
protocol layers is a mistake.

>   One way this mechanism could be provided would be to use a bit in the
>   AH Reserved field to indicate that the authenticated information
>   begins at the start of the AH header and ends at the end of the IP
>   frame.  This would permit evolution while not encountering the export
>   problems folks feel is associated with ESP.

I think i could live with this, and it might not be too hard to do.

>   assignment that IPv6 is trying to meet, it seems like promoting the
>   use of the IP address as a security identifier will make it more
>   difficult for our IPSEC customers in the future when the identifiers
>   change and certificates have to be replaced (and, I suspect,
>   associated CRLs updated, etc.).  I do not think that this is the
>   direction we want to be going.

I'll remind you that IP addresses are supposed to be used as part of a
security identifier; an address along with an SPI indicates the SA to
use. 

Additionally, i don't see how dynamic IP will be hampered by IPsec in
this respect, assuming a well thought out certificate scheme is in
place; specifically, certificates for mobile agents should not include
any IP addresses (this is a necessary but probably not sufficient
condition).

>   negotiation protocol would have to be aware during the negotiation
>   process of the IP version being protected.  That seems rather
>   complicated to me.  I would instead suggest the architecture or ESP
>   doc require that IV field size MUST be a multiple of 64 bits, and
>   also specify how to pad IVs of other sizes to a multiple of 64 bits.
>   Since most algorithms that I am aware of already use 64-bit IVs, this
>   would not cause any additional processing.  It would make it so that
>   (some vendor's) deployed software would not suddenly break when a new
>   algorithm which uses other sized IVs is deployed in the future.  What
>   do others think about making this a requirement?

I'm puzzled by this. Why wouldn't the standard padding at the end of
the ESP payload be enough to handle alignment problems ?
-Angelos
References: