[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Last-call (RE: [rohc] I-D ACTION:draft-ietf-rohc-rtp-07.txt)
Hi Haihong,
At 06:27 PM 2/2/01 -0600, haihong.zheng@nokia.com wrote:
>Hi, Carsten and all,
>
>I have one question on section 5.8.4.3.
>
>It is said in the draft that "A compressed item consists of a compressed
>sequence number. When an item is compressed, Padding and Next Header are
>removed near the end of the packet." I think you are talking about encrypted
>Padding and Next Header fields.
No. 5.8.4.3 applies ONLY when the NULL encryption algorithm is used with
ESP. In this case only the payload is not encrypted, and only the authentication
mechanisms are used. If the payload truly is encrypted, then list compression will not
be used and the packet is sent using the ESP profile or the UNCOMPRESSED profile.
This is explained in the first two paragraphs of 5.8.4.3, and also mentioned
in the beginning of 5.7.7.7. I do hope that text is clear enough. Please read it
again and see if there is a problem.
There is a (very small) possiblity that the fields in question have values that
appear to be in cleartext, when in reality they are not. Several packets in a row
need to be like this (and a number of sanity checks need to be met) for any
context damage to occur. This is an extremely unlikely situation and will correct
itself as soon as a packet arrives where the encrypted values in the positions
of the fields in question do not correspond to reasonable cleartext values.
>But there are two problems here: First, the
>encrypted data of the same field may not be the same as the one in the last
>packet.
This is not a problem since the fields are not encrypted.
>Second, removing these encrypted fields may affect the decryption of
>the rest fields.
The fields will obviously have to be insterted by the decompressor. Otherwise,
the packet could not be authenticated. (Note that no decryption is needed, the
packet is not encrypted!)
There is enough information present to reinsert the fields. The Pad Length
field was left in place precisely to allow such re-insertion of the fields in question.
This all seems obvious to me. However, since the issue has been raised:
do you think it needs to be stated explicitly that the fields are to be reinserted?
If so, we might add the sentence "All removed fields must be reinserted when
decompressing the packet." as the next-to-last sentence of 5.8.4.3.
Cheers,
Mikael Degermark
>I'm not an expert in encryption algorithm. If someone has
>any knowledge in this area, please comment.
>
>BR,
>
>Haihong
>
>-----Original Message-----
>From: ext Dr. Carsten Bormann [mailto:cabo@tzi.org]
>Sent: 2. February 2001 7:40 AM
>To: rohc@cdt.luth.se
>Cc: Mikael Degermark
>Subject: Last-call (RE: [rohc] I-D ACTION:draft-ietf-rohc-rtp-07.txt)
>
>
>ROHCers,
>
>as announced previously, we are now holding a five-day abbreviated WG
>last-call for:
>
> draft-ietf-rohc-rtp-07.txt
> (http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-07.txt)>
> draft-ietf-rohc-rtp-requirements-04.txt
>
>(http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-requirements-04.txt
>)
>
>(Note that there are no changes to, and thus no need to last-call again,
> draft-ietf-rohc-rtp-lower-layer-guidelines-00.txt.)
>
>-- Since you all could get the document from the ROHC web site, have
> already seen intermediate snapshots there, and since the changes
> are minor, this second last-call is limited to five real-time days
> from the minute of announcement on the IETF-announce mailing list.
>
> The last-call ends 2001-02-07 1400 UTC.
> Please comment quickly...
>
> Please direct comments to the ROHC mailing list, rohc@cdt.luth.se
>
>-- If in the second WG last-call period any significant changes turn
> out to be required, we have to generate a new document and
> last-call that again. (In any case, unless there are no changes
> from the second last-call period at all, we will have to generate a
> new revision of the I-D before the IESG last-call.)
>
>Gruesse, Carsten
>
>---
>Mailing list for Robust Header Compression WG
>Archive: http://www.cdt.luth.se/rohc/
>