Subject: 2.5g/3g last call

From: Mark Allman <[email-masked]>
Date: Thu, 19 Jul 2001 10:23:12 -0400

> Just a reminder that we are in last call for
> draft-ietf-pilc-2.5g3g-03.txt.  A list hum would be helpful to the
> chairs. Is this document complete?  stable? accurate?

No hum here.  (In fact, I cannot even imagine why this document is
being last called given it's state.)

Below are a slew of comments on the draft.  Most are simply
editorial and should be easily fixable.  My next message will
outline my single biggest complaint with the draft.

  * Section 2: Note note that the characteristcs are ARQ, FEC "and
    so on".  I'd suggest nuking "and so on" and replacing it with
    something more meaningful (like a short list of other items), or
    at least a little more formal (like "as well as several other
    minor characteristics as discussed in [1]").

  * Section 2: "(PDUs) 336" --> "(PDUs) that are 336"

  * Section 2: You need to define "SDU".

  * Section 2: "unit for retransmission" --> "unit for link layer
    retransmission"

  * Section 2, third paragraph, first sentence:  tack "in many of
    these systems" onto the end of your "sentence".

  * Section 2, paragraph 4: This is all about link-layer stuff,
    right?  I'd nuke the reference to TCP self-clocking.  It doesn't
    seem to add anything here and I believe it confuses things quite
    a bit.

  * Section 2: You note the BDP of your networks are "relativly
    large".  What does this mean?

  * Section 3.1.1: This section essentially says nothing.  I suggest
    nuking everything but the last paragrph -- which says exactly
    what you need to say.  The rest of the words are fuzzy and do
    not add anything.

  * Section 3.1.2: "the very first slow start turn, that" --> "the
    first RTT of slow start which"

  * Section 3.1.2: "more than two." --> "more than two segments."

  * Section 3.1.2: "and the gateway and could set the CNWD" --> "and
    the gateway.  Setting the CWND"

  * Section 3.1.2: "mobile node." --> "mobile node may allow for
    performance benefits without using a larger initial congestion
    window on the Internet."

  * Section 3.1.2: Reword the last sentence of the next to last
    paragraph to something like: "Note: There are a number of
    possible implications for using connection splitting techniques
    that network designers should be aware of before employing such
    mechanisms.  See [36] for a discussion."

    (Also note that [36] is now an RFC.) 

  * Section 3.1.2: The last two sentences of the section do not make
    any sense to me.  I think the following would be a more clear
    way of saying what I think you're getting at in the
    second-to-last sentence: "A CWND > 2 segments may be used
    between a gateway and a mobile node."

    However, the last sentence just has me baffled.  What is the
    point there?

  * Section 3.1.3: "is extending" --> "extends"

  * Section 3.1.3: "that is not enough to generate" --> "that are
    not likely to generate the" 

  * Section 3.1.3: "duplicate acknowledgments." --> "duplicate
    acknowledgments required to trigger fast retransmit."

  * Section 3.1.3: "when congestion window" --> "when the congestion
    window"

  * Section 3.1.4: "The large MTU" --> "A larger MTU"

  * Section 3.1.4: "In the links with errors" --> "In links with
    high error rates"

  * Section 3.1.4: "is better in terms of" --> "increases"

  * Section 3.1.4: "Rate), condition." --> "Rate) condition."
    
  * Section 3.1.4: "link, smaller" --> "link, a smaller"

  * Section 3.1.4: "MTU is better." --> "MTU is recommended."

  * Section 3.1.5: "unit for" --> "unit (without IP layer
    fragmentation) for"

  * Section 3.1.5: "default MTU" --> "default (small) MTU"

  * Section 3.1.6: "data grows big." --> "data increases."

  * Section 3.1.8: I suggest changing "Summary" to "Recommendations"
    or "Summary of Recommendations" or something.

  * Section 4: "Other ideas" --> "Additional ideas"

  * Section 4: "include the ROHC" --> "include ROHC"

  * Section 4: ", RFC2309" --> ", and RFC2309"

  * Section 4: "We have been" --> "We are also"

  * Section 4: "because the Web" --> "because Web"

  * Section 4: "we did not" --> "we do not"

  * Section 4: "Eifel" --> "The Eifel"

  * Section 4: "thereby solving" --> "thereby mitigating"

  * Section 4: "the problems" --> "the performance problems"

  * Section 4: Nuke the "It is promising..." sentence.

  * Section 4: "can know what" --> "is informed of the"

  * Section 4: "and infer" --> "and may infer"

  * Section 4: I can't figure out what the paragraph on RFC 2988
    adds.  I'd suggest nuking it.  

    Also, the RFC states that the initial RTO must **NOT** be less
    than 3 seconds.

  * Section 5: What is "RAN"?

  * Meta-comment: You should not discuss the "window".  You should
    always qualify it as either the "advertised window" (or,
    "receive window") or the "congestion window" to avoid ambiguity.

I hope that helps.  I really do, because I have been typing for a
long damn time...

allman

---

From: "Hiroshi INAMURA" <[email-masked]>
Date: Fri, 27 Jul 2001 02:16:02 +0900

> There's a difference between limited user devices, and end users.
>
> And these are deployed *by the network operator*, right? Can the user
> choose other e2e security methods?

If  you use non-'limited user devices' (such as Linux/BSD installed laptop
or such) over 3G network, you can use your favorite E2E security mechanism.

For i-mode handset, there is no choice for IPsec. In that sense, you are
right.

Hiroshi

---

From: Bill Yeager <[email-masked]>
Date: Thu, 26 Jul 2001 10:44:30 -0700 (PDT)

| > There's a difference between limited user devices, and end users.
| >
| > And these are deployed *by the network operator*, right? Can the user
| > choose other e2e security methods?
| 
| If  you use non-'limited user devices' (such as Linux/BSD installed laptop
| or such) over 3G network, you can use your favorite E2E security mechanism.
| 
| For i-mode handset, there is no choice for IPsec. In that sense, you are
| right.

I don't think you will see IPsec as a choice in handsets for a long time for
securing e2e communication.

TLS and SSL will be prevelant. And, right, users don't select the mechanism. 

Bill

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 26 Jul 2001 20:18:38 +0200

Lloyd Wood wrote:

> On Fri, 27 Jul 2001, Hiroshi INAMURA wrote:
>
> > > ciphertext is not a good term to use, as it implies ascii
> > > text
> >
> > I do not think so. 'ciphertext' is generic word. My definition came from
> > "Applied Cryptograpy 2nd ed." pp.1.
>
> ciphertext contrasts with plaintext. As I said (and as the words
> clearly imply) this implies *text* and can be misread as such.

Not at all.

Even though both words have the substring 'text' in them, that is
absolutely inconsequential. Both 'plaintext' and 'ciphertext' are basic
terminology in the crypto literature, and as such have  very well defined
meanings and usage. For another example, see the 'Handbook of Applied
Cryptography' (Menezes, van Oorschot and Vanstone) in which offers these
examples of 'plaintext': binary strings, English text, computer code, etc.

-gabriel

---

From: "Hiroshi INAMURA" <[email-masked]>
Date: Fri, 27 Jul 2001 01:16:35 +0900

> > air and as cleartext between the Radio Access Network (RAN) and the core
> > network.   IP security RFC2411[33] or TLS RFC2246[32] can be deployed
>
> by whom? the network operator?

By user devices. E2E security should not involve network operator by its
definition.

Hiroshi

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 26 Jul 2001 15:41:41 +0100 (BST)

On Thu, 26 Jul 2001, Hiroshi INAMURA wrote:

> For section 5, updated text is here.
> 
> Hiroshi
> 
> ----- Original Message -----
> From: "Mark Allman" <[email-masked]>
> Sent: Thursday, July 19, 2001 11:23 PM
> Subject: 2.5g/3g last call
> 
> 
> 5. Security Considerations
> 
>    In 2.5G/3G wireless network, data in transmitted as ciphertext over the

data *is*. ciphertext is not a good term to use, as it implies ascii
text.

> for
> end-to-end security. The use of a transport gateway as mentioned in Section
> 3.1.2 introduces conflicts with IP-Sec; however TLS can be used in such
> architectures.

well, that's pretty vague; I'm not sure it's useful, but I'm by no
means a security expert.

(Dan?)

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 26 Jul 2001 17:34:33 +0100 (BST)

> By user devices. E2E security should not involve network operator by its

Yet the network operator/architect is in a position to enable NAT and
any number of other things to make e2e security deployment hard to
impossible. (Can e2e security actually be used across iMode or WAP?)

And you're in the position of writing recommendations for said network
operator/architect. So what should you recommend?

L.

---

From: "Hiroshi INAMURA" <[email-masked]>
Date: Thu, 26 Jul 2001 23:20:35 +0900

Hiroshi

----- Original Message -----
From: "Mark Allman" <[email-masked]>
Sent: Thursday, July 19, 2001 11:23 PM
Subject: 2.5g/3g last call

network.   IP security RFC2411[33] or TLS RFC2246[32] can be deployed for

---

From: "Hiroshi INAMURA" <[email-masked]>
Date: Fri, 27 Jul 2001 01:47:26 +0900

> impossible. (Can e2e security actually be used across iMode or WAP?)

SSL has already deployed on the i-mode handset. WAP2.0 will recommend TLS.

Hiroshi

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 26 Jul 2001 17:53:16 +0100 (BST)

L.