Subject: [Seamoby] DoCoMo Implementation Issues with CTP

From: "James Kempf" <[email-masked]>
Date: Tue, 17 Feb 2004 14:21:29 -0800

DoCoMo is in the process of implementing CTP, and we came up with the
following list of issues in the spec. Since none of them seem particularly
large, Allison suggested that we simply update the current version of the
document (which is now under review by the ROHC WG) in place, without reving
the document to a new version. She will make the changes.
Below, a list of the issues and suggested changes to the document to address
them.

Any comments? Please let me know by March 6.

            jak

-------------------------------------------

1) Section 2.5.1, pg. 10; Section 2.5.2, pg. 11; Section 2.5.3, pg. 12;
Section 2.5.4, pg. 13; Section 2.5.6, pg. 15 - 'V' flag

The spec allows CTP messages to carry both IPv4 and IPv6 addresses, but as a
practical matter in the implementation, a CTP message will be sent to the
IPv4 or IPv6 address of a router. Processing the address of the opposite
version in the stack is complicated. Suggestion is to only allow IPv4 or
IPv6 addresses, but keep the flag field size at 2 bits in case further
experience shows that there are reasons why both might be sent. The router
can issue separate messages if both addresses must be changed,  Suggested
change in text:

Replace: "When set to '10', indicate presence of both IPv6 and IPv4 Previous
(New) addresses."
With: "Values of '10' and '11' are reserved".

2) Section 2.5.3, pg. 12 - Length of Algorithm field in CTD message block.

The length of the algorithm field in the CTD message block is shown as 17
bits. It should be 16.

3) Section 2.5.1, pg. 10; Section 2.5.2, pg. 11; Section 2.5.3, pg. 12;
Section 2.5.4, pg. 13; Section 2.5.6, pg. 15 - Length field.

The size of the message length field is currently 8 bits, and the units for
the length are in 8 octet words. This allows a maximum of 2048 octets, which
might not be enough for bundling large amounts of context if padding is
required. Suggestion is to increase the size of the field and make it be
units of octets, for a total of 65535 octets. This would only involve moving
the flags into the Reserved field, and would not otherwise modify the
message.

Replace: In message diagram blocks, move Length to be 16 bits rather than 8.

Replace: "Length    message length in units of 8 octet words"
With: "Length    message length in units of octets"

4) Section 2.5.1. pg. 9; Section 2.5.2, pg. 11; Section 2.5.3, pg. 12;
Section 2.5.4, pg. 13; Section 2.5.5, pg. 14; Section 2.4.6, pg. 15 - IP
address field size.

The message block diagrams show the size of the IP address fields as 4
octets, but if the IP address is for IPv6, it will be 16.

Replace: In the message block diagrams, replace the final "|" with a "~" to
indicate a variable length field. Indicate variable length field by putting
"(4 or 16 octets)" after the text in the field.

5) Section 2.5.3, pg. 12 - Key field in message diagram

Only 4 bytes are shown for the key field, but the key size field allows
65535. The message diagram needs to be changed.

Replace: In the message diagram, replace the final "|" with a "~" to
indicate a variable length field. Indicate the variable length field by
putting "(variable)" after the text in the field.

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

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 18 Feb 2004 17:46:46 -0800

Jim,

the suggested changes are okay. I am curious about couple
of suggestions however..

- When both IPv4 and IPv6 addresses are used in CTD,
 "Processing the address of the opposite
version in the stack is complicated. " Could you elaborate on
this ? I can see that once IP (v4 or v6) stack demultiplexes the
packet to belong to a CTP client, it would just forward the block
to a CTP module (a daemon for instance), which could then
process contexts associated with both the addresses.

- Isn't MTU a consideration in increasing the size of the
    Length field to 16 bits ?

Thanks,

-Rajeev

---

From: "Raghu" <[email-masked]>
Date: Thu, 19 Feb 2004 15:58:34 -0800

Hi Rajeev,

Please find my comments below

regards,
Raghu

> process contexts associated with both the addresses.
IP Version flag in the draft indicates whether the IP Version
can be either IPv4 or IPv6 or both(IPv4 & IPv6).
When MN is assigned both IPv4 & IPv6 addresses,
it is assumed that AR also has both IPv4 & IPv6 addresses.
When MN moves, sending two CT messages for the same MN
is unnecessary. Hence to avoid this, either IP version flag
should not support both IPv4 & IPv6 at the same time or
the draft should mention, which IP version to take precedence.

>     Length field to 16 bits ?

Since CTP is an application layer program, I guess
supporting upto 16bits is more reasonable for the
following reasons
1. UDP supports upto 16bits
2. As more Feature profiles are defined more
    contexts in the same CTP needs to be transferred.

As per the sections 2.4 & 2.5 in the draft
"message length in units of 8", Padding bytes
 are required for both CDB & CT Messages.
These padding bytes get critical when we are
reaching the maximum size ie 2048 bytes.

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 19 Feb 2004 17:01:40 -0800

Hello Raghu,

> is unnecessary. Hence to avoid this, either IP version flag

hmm.. This is perhaps a misunderstanding.
The `V' bits indicate whether contexts corresponding to
both IPv4 and IPv6 addresses (as well as the addresses
themselves) are present. The (P)CTD message itself
can be either IPv4 or IPv6. You may observe that the
Source and Destination IP addresses for all the messages
are absent. I cannot say this is intentional, but the result is
that the messages themselves can be carried in IPv4 or IPv6
packets.

> the draft should mention, which IP version to take precedence.

Hopefully, the above explanation clarifies..(i.e., IP version of
the packets carrying CTP messages is independent of the
`V' bits).

Length field increase (below) is okay.

-Rajeev

---

From: "Raghu" <[email-masked]>
Date: Thu, 19 Feb 2004 17:22:41 -0800

> the packets carrying CTP messages is independent of the
I understand your point, but
I request you to explain how the implementation should be 
in the following scenario ?

When MN moves, MN sends CTAR to nAR,
nAR needs to extract IP information from CTAR and send a CTREQ to oAR.
When both(IPv4 & IPv6) are present in CTAR, What is the behaviour of nAR ?

regards,
Raghu

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 19 Feb 2004 17:35:01 -0800

> When both(IPv4 & IPv6) are present in CTAR, What is the behaviour of nAR ?

In CTREQ, set `V' to 10, include both IPv4 and IPv6 addresses in
"Mobile Node's Previous IP Address" field, construct
IP Dest = PAR's IP (v4 _or_ v6) address provided in CTAR
IP Src = NAR's IP (v4 or v6) address.

Is the confusion in whether `V' bits also refer to
PAR and NAR addresses ? If so, we should clarify that they
refer to MN's IP addresses only, and that the router address
must be either IPv4 or IPv6 but not both.

-Rajeev

---

From: "Raghu" <[email-masked]>
Date: Thu, 19 Feb 2004 18:11:09 -0800

> IP Src = NAR's IP (v4 or v6) address.
IP Dest is the confusing part, I guess clarification in the draft, helps.

Question based on your suggestion,
When Context trigger is generated, pAR sends PCTD to nAR.
Let us say,
IP Dest = NAR's IP (IPv4) is used and
IP Src = PAR's IP  (IPv4) is used to send PCTD to nAR

When MN sends CTAR with PAR= IPv6 to nAR,
How does nAR verify and enable the contexts ?

> must be either IPv4 or IPv6 but not both.
This description in the draft may clarify things, but how to
identify the IP version AR in CT messages.
I guess another V flag for AR might simply things.

regards,
Raghu

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 19 Feb 2004 18:32:26 -0800

> How does nAR verify and enable the contexts ?

Well, CTAR includes MN's IP(v4,v6) addresses. So does
PCTD. So, nAR can still match the contexts. Since the token
does not include PAR's address, verification can still be
done.

> I guess another V flag for AR might simply things.

Perhaps this is not necessary. (See above)

-Rajeev

---

From: "Raghu" <[email-masked]>
Date: Thu, 19 Feb 2004 18:55:20 -0800

> does not include PAR's address, verification can still be
I think I didnot make my point clear.
MN is claiming that it came from one pAR IP Address(IPV6),
but the nAR has a PCTD that says pAR IP is different(IPv4),
How can nAR verify the Token without matching the pAR IP ?

> Perhaps this is not necessary. (See above)
I mean,
In CTAR Message there is pAR IP,
how can nAR know that there is IPv4 or IPv6 address of pAR,
if the V flag is only for MN IP version.

regards,
Raghu

---

From: "James Kempf" <[email-masked]>
Date: Fri, 20 Feb 2004 09:39:53 -0800

Yes, that sounds like the confusion.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 20 Feb 2004 09:37:26 -0800

Rajeev,

Could you suggest some text for the draft that clarifies this point?

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 20 Feb 2004 10:15:31 -0800

Hi Raghu,

> How can nAR verify the Token without matching the pAR IP ?

The intended reason for including PAR's IP address in CTAR is
to allow NAR to construct CTREQ and send it to PAR.
When PCTD takes place, there is no reason to do CTREQ.
(Also, note that you could not match contexts using PAR's IP
address since that could yield many contexts corresponding to
multiple MNs.)

The token calculation does not include PAR's address. It
only includes MN's previous address (note: when V is 10 in
CTAR, the token should include both the IP addresses).
Since the MN includes both its addresses and NAR has
contexts for both of those addresses, they can be matched.
The token calculation on NAR is also done in a similar way
as in the MN; PAR's address is not a parameter in computing
the token.

Is this better ?

> if the V flag is only for MN IP version.

MN includes the PAR's address in CTAR. NAR should use that
address in the Dest field of CTREQ.
Perhaps we should state that the MN should only include the
IPv4 address of PAR (NAR).

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 20 Feb 2004 10:36:27 -0800

Revise the current definition of `V' flag from

"When set to '00', indicate presence of IPv6
   Previous (New) address only." etc. to

"When set to '00', indicate presence of _MN's_IPv6
   Previous (New) address only. etc.

Also I suggest that the field "Previous (New) Router IP Address"
be revised to "Previous (New) Router IPv4 Address"

And, when `V' is 10, the token calculation should include
both IPv4 and IPv6 addresses. So, to the following,

"First (32, HMAC_SHA1 (Key, (Previous IP address | Replay | Context
      Types))), where Key is the shared secret between the MN and pAR,
      and Context Types includes all the desired contexts for which the
      transfer is desired. In the default scenario, the MN implicitly
      (i.e., even without the knowledge of contexts being present) or
      explicitly requests transfer of all contexts."

add

"When contexts corresponding to both IPv4 and IPv6 addresses are
present (i.e., `V' is 10), the calculation is performed as
First (32, HMAC_SHA1 (Key, (Previous IP v4 address | Previous IPv6
address | Replay | ContextTypes)))."

-Rajeev

---

From: "Raghu" <[email-masked]>
Date: Fri, 20 Feb 2004 10:42:27 -0800

> to allow NAR to construct CTREQ and send it to PAR.
okay.

> When PCTD takes place, there is no reason to do CTREQ.
Right.

> address since that could yield many contexts corresponding to
I was also under impression that both (PAR IP & MN IP) 
from CTAR & PCTD must match before verifying the token.
Otherwise how can nAR determine from 
which pAR a MN is comming from ? 

> as in the MN; PAR's address is not a parameter in computing
Yes.

> IPv4 address of PAR (NAR).
It helps.

regards,
Raghu

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 20 Feb 2004 11:07:22 -0800

> which pAR a MN is comming from ?

Why is it necessary to know PAR's IP when the contexts
are already there ?

-Rajeev

---

From: "Raghu" <[email-masked]>
Date: Fri, 20 Feb 2004 11:14:13 -0800

> Why is it necessary to know PAR's IP when the contexts
For two reasons,
1. To avoid picking up of any Stale contexts due to frequent moving of MN.
2. Security. 

regards,
Raghu

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 20 Feb 2004 11:20:27 -0800

> 1. To avoid picking up of any Stale contexts due to frequent moving of MN.

I cannot readily figure out how PAR's IP helps here..

> 2. Security.

If the token matches, the MN must have had an SA
with PAR.

-Rajeev

---

From: "Raghu" <[email-masked]>
Date: Fri, 20 Feb 2004 11:58:54 -0800

> I cannot readily figure out how PAR's IP helps here..
For example,
Consider 3 ARs  A, B & C
MN moves from A to B, so A sends PCTD to B.
But MN never sends CTAR to B but instead moves to C
and sends CTAR to C with pAR as A.
Now C gets the contexts from A and MN stays here
for a short time and now moves back to A and immediately to B.
Again A sends PCTD to B.
When MN sends a CTAR to B, which PCTD should be used ?

Also incase of Mobile IP where MN IP doesnot change,
and MN moves from A to B (A sends PCTD to B,
MN doesnot send CTAR) instead moves to C then
to B(C sends PCTD to B, MN sends CTAR to B),
which PCTD should B use ?

> If the token matches, the MN must have had an SA
Probably security is not a major concern as
CTP assumes prior SA (like IPSEC) between ARs to transfer CTP.

regards,
Raghu

---

From: "James Kempf" <[email-masked]>
Date: Fri, 20 Feb 2004 14:26:08 -0800

> be revised to "Previous (New) Router IPv4 Address"

What happens is the router only has an IPv6 address?

How about:

    Previous (New) Router IP address, or, in the case of dual stack routers,
IPv4 address.

                jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 20 Feb 2004 15:08:12 -0800

> What happens is the router only has an IPv6 address?

I hope that will be the case one day!

>     Previous (New) Router IP address, or, in the case of dual stack routers,

We could state the default is IPv4 unless no IPv4 support is available.
That is, simply re-word above as PAR (NAR) IP Address, default
being IPv4.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 20 Feb 2004 18:33:20 -0800

Sounds fine.

I'll write up the changes and send them to Allison.

            jak

----- Original Message ----- 
From: "Rajeev Koodli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Raghu" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Friday, February 20, 2004 3:08 PM
Subject: Re: [Seamoby] DoCoMo Implementation Issues with CTP