TIA_835-D, cdma2000 wireless IP Network Standard (Dec 2005)
Ballot Review process
Ballot Review please use these files:
TIA-835-D chapter1.pdf
TIA-835-D chapter2.pdf
TIA-835-D chapter3.pdf
TIA-835-D chapter4.pdf
TIA-835-D chapter5.pdf
TIA-835-D chapter6.pdf
1.
#
2.
#
3.
Source
4.
Chapter
5.
§
6.
Page
7.
Line
8.
E-T
Cisco 2 3.2.2 12 25 T
9.
Res.
10.
Comment/SF file ID
Cisco
Cisco
Cisco
2
2
2
3.2.3 14
4.2.1.4 23
4.3.6 32
24-25 E
28-30 T
17-18
The spec is still very vague about how dual IPv4/IPv6 sessions use
Radius. One record, two records, start/stop?
Remove the second sentence “See section 5.2.2 for MIP6 ingress filtering” to avoid circular referencing plus this section is for Simple
IP not Mobile IP.
Why is implementing DNS server assignment important for MIP on the PDSN? Preferred method should be sending DNS server using
MIP signaling.
If the HA receives a Registration Request with the 'G' bit set but without the GRE Key CVSE, it shall reject the call by sending a
MIP4 RRP with code ‘Poorly Formed Request (0x86)’.
Comment - Why should HA reject an RRQ with 'G' bit set and no
CVSE. It is not backward compatible.
11
Editor’s NOTES

Cisco 2
Cisco 2
Cisco
Cisco
Cisco
2
2
2
5
5
5
4.3.6 32 19-21 T
5 39 8-13 E
39
40
41
34
4-6
E
E
E
Change to:
If the HA receives a Registration Request with a GRE Key CVSE but without the ‘G’ bit set, the HA should treat this as if ‘G’ bit is set in the Registration Request, i.e., the presence of GRE Key CVSE indicates a request for GRE encapsulation. In this case, the HA shall not send the “G” bit in the RRP.
In order for the MS to authenticate and authorize with the home network, the MS includes the MN-NAI mobility option [RFC 4283] and the Mobility Message authentication option [RFC 4285]. This type of authentication and authorization allows the MS to perform
Home Registration without IPsec. The HA can authenticate and authorize the MS based on identity credentials that are included in the BU such as the MN-HA authentication mobility option or the MN-
AAA authentication mobility options [RFC 4285].
Comment - Should use consistent terminology: MN-HA mobility message authentication option / MN-AAA mobility message authentication option. If you want to shorten this then just use MN-
HA/MN-AAA authentication option. This is for the entire MIP6 section.
Fig 7 mismatch in names of options in BU/BA
Should refer to Figure 8 and not Figure 9 a) The MS sends a BU to the HA. The BU includes the Mesg-ID mobility option and the MN-HA authentication mobility options.
The BU may also include the MN-NAI mobility option. The MN-
HA authenticator mobility option is computed with the IK.
Comment - Typo. See earlier comment about authentication option terminology consistency.

Cisco 2
Cisco 2
5 41 7-12 T
5.3.1 52 13-18 T b) The HA authenticates the BU by verifying the authentication data of the MN-HA authentication mobility data using the stored
IK. The HA performs replay check using the Mesg-ID mobility option. If both authentication and replay check succeeds, the
HA sends a BA back to the MS. The BA contains the MN-HA authentication mobility option and the Mesg-ID mobility option.
The BA may optionally contain the MN-NAI mobility option.
Comment - BA must contain MN-NAI mobility option if BU included the option?
5.3.1 Home Agent Requirements to Support Dynamic Home
Agent Assignment
The HA shall support Dynamic Home Agent Address
Discovery as defined in [RFC 3775].
The HA shall process Binding Updates that contain Mobility message authentication options (MN-HA or MN-AAA), Mesg-
ID option and optionally, the MN-NAI mobility option. If the
MN-NAI mobility option is not included in the initial BU of an
MS, the HA shall treat it as an error and shall reject the BU.
Comment - IK is not available to send rejection

Cisco 2
Cisco 2
5.3.2 52 20-23 T
5.3.3 52 32-35 T
The Home Agent shall support Home Addresses that are either assigned by the Home RADIUS server or auto-configured by the Mobile Station as long as the use of the Home Address by the user (NAI) is authorized by the Home RADIUS server and the optional proxy Duplicate Address Detection procedure on the Home Link passes
Comment - What VSA is in the Access-Accept to authorize an auto-configured HoA?.
The HA shall support Multiple home registrations with the same NAI but different Home Addresses. The Binding Cache
Entry (BCE) in the HA shall be indexed with the NAI and the
Home Address of the MS at a minimum. The HA shall rely on the Home RADIUS server to authorize a user to perform multiple simultaneous home registrations on the same home link.
Comment - BU may not have NAI, so index by both is problematic. Indexed by HoA to BCE will work.

Cisco 2
Cisco 2
Cisco 2
5.3.3 52 36-40 T
5.3.4.1.1
.1
53 18-19 T
5.3.4.1.1
.1
53 35-38 T
The MS is allowed to send more than one Binding Update for home registration with different HoAs and with same or different CoAs. Whether these home registrations will be allowed or disallowed depends on the Home Network provider’s policy. If Multiple registrations are not authorized, the HA will receive a RADIUS Access-Reject message for subsequent home registration authorization.
Comment - How does HA inform the MN rejection due to unauthorized used of multiple HoAs? Consider the case MN registers with HoA1, then crashed, and comes up with a new
HoA2. When MN registers with HoA2, HAAA says “no”.
Does HA update BCE with HoA2 or reject BU?
If the SPI in the BU is not set to HMAC_CHAP_SPI the HA shall reject the BU using reject code 129 (Administratively prohibited) [RFC 3775].
Comment - Cannot reject unless IK is available.
The HA shall cache the Integrity Key (IK) as the MN-HA shared secret for each of the registered NAI and HoA pair to process BUs when BCE lifetime > 0. The IK is cached in a security association in the BCE and is associated with SPI=5.
Thus, SPI=5 is associated with the dynamically derived security association between MS and HA
Comment - Cannot be pair because NAI option may not be in
BU.

Cisco 2 5.3.4.1 53 5 T 5.3.4.1 Authentication Protocol Based Home Registration
Support
The HA shall support MIP6 authentication protocol as defined in
[RFC 4285] and the MN-NAI mobility option as defined in [RFC
4283]. Upon receiving the initial BU, the HA shall perform authentication of the BU based on the Mobility Message authentication option and the MN-NAI mobility option. Upon receiving the subsequent BU, the HA shall perform authentication of the BU based on the Mobility authentication option, HoA and optionally, the MN-NAI mobility option.
Comment - The wordings above does not seem right. The initial BU is authenticated using the MN-AAA option and subsequent BUs are auth. using MN-HA auth option.
The spec seems to say that the initial BU must have MN-NAI mobility option, but subsequent BU may not have this option.
Though initial BU has MN-AAA auth opt and subsequent BU has
MN-HA auth opt. The spec needs to keep the identification of the
MN (either NAI or HoA) independent of the authentication method
(MN-HA or MN-AAA).

Cisco 2
Cisco 2
5.3.4.1.2 54 6-9 T
5.5.4 60 17-19
Section 5.3.4:
The initial BU (the BU is considered initial when the HA does not have a BCE for the NAI and the HoA pair) contains MN-HA authentication mobility option, the HA shall reject the BU for the initial Home Registration. In this case the HA shall use reject code
129 (Administratively prohibited) [RFC 3775].
Comment - How can the HA reject this BU - it does not have a key to auth BA. HA just drops the BU. Also, why is BCE indexed by
NAI _and_ HoA pair? This is not possible if the NAI mobility option is not in the BU.
Section 5.5.4:
MIP6 Home Registration is performed when the MS sends a
Binding Update message to the HA. The MS shall include the
MN-NAI mobility option in the initial BU. The inclusion of the MN-NAI mobility option in the subsequent BUs is optional.
Comment - The last statement is probably not completely true. The reason being, if there are multiple registrations, they are indexed by NAI and then the IP. So, at least in that case, having NAI too is a must.
MN should add NAI option and MN-AAA Auth option if it is not receiving BA for BU w/o NAI option. This allows recovery if BCE was deleted.

Cisco 3
Cisco 3
Cisco 4
Cisco 4
5.2.2 22 34-37
5.2.3 23-24 39-
40/
1-2 all all all
3.1.1 6 15-17 E
Since the FA-HA Authentication extension is optional need to reword the last statement as :
For all Mobile IP sessions that previously negotiated GRE encapsulation and GRE Key using the GRE Key CVSE, the PDSN shall include GRE Key CVSE with the PDSN-assigned key value in all Revocation and Revocation Acknowledge messages. "The GRE
Key CVSE must be included before the FA-HA Authentication extension, if this extension is present".
Since the FA-HA Authentication extension is optional need to reword the last statement as :
For all Mobile IP sessions that previously negotiated GRE encapsulation and GRE Key using the GRE Key CVSE, the PDSN shall include GRE Key CVSE with the PDSN-assigned key value in all Revocation and Revocation Acknowledge messages.
"The GRE
Key CVSE must be included before the FA-HA Authentication extension, if this extension is present".
Comment - Need to have a separate section for HRPDspecific items? The current layout makes it difficult to identify those items.
Change to:
MS shall use the service connection that carries the
Reservation Label 0xfe as the auxiliary service connection for best effort traffic of IP flows without HDLC-like framing and without PPP encapsulation.

Cisco 4
Cisco 4
3.1.1 6 21-24 E
3.1.1 6 25-29
For cdma2000® 1xWhen the MS already has a packet data service on a cdma2000® 1x (or HRPD) air interface with an established auxiliary service connection in addition to the main service connection if the MS uses MIP, the MS may send MIP agent discovery and registration messages over the auxiliary service instance.
Comment - This paragraph needs rephrasing.
The MS is not required to send TFT to the PDSN for the main service connection and the auxiliary service connection that carriers best effort traffic of IP flows without HDLC-like framing and PPP encapsulation. The MS shall send Traffic
Flow Templates for flow mapping to the PDSN for support of other auxiliary service connections, and it shall update the TFT when any of the TFT components change (e.g., MS IP address, packet filter components).
Comment How does the PDSN differentiate downstream best effort traffic destined for the flow identified by Label 0xff from best effort traffic destined for the flow identified by
Label 0xfe?

Cisco 4 3.1.2.1 7 7-14 If both checks are “negative”, for HRPD the PDSN proceeds with PPP negotiation. For cdma2000® 1x, the PDSN shall determine if the first established A10 connection is of SO type
33 to initiate PPP negotiation with the MS. If the first A10 connection is not of SO type 33, the PDSN shall set the timer
Twait_main
1
to wait for an A10 connection of SO type 33 to carry out PPP negotiation. If the timer Twait_main expires and the RAN has not established an A10 connection with SO type
33, the PDSN shall release the already setup A10 connection(s).
The PDSN shall store the received CANID from the
NVSE field if received in the A11 Registration-Request and shall associate it with the A10 main service connection for the MS for future comparison.
Comment - Section 3.1.1 states that PPP Negotiation must be done using Service Option 59. Doesn’t HRPD need a check for first A10 connection is of type SO59 otherwise wait?. Section
3.1.2.2 had text for this but it has been deleted. Seems to be some inconsistency on whether SO59 is a must for HRPD PPP negotiation flow.
1 Twait_main is described in Annex D.

Cisco 4
Cisco 4
3.2.1 9 10-16 T
3.2.1 9 17-18 E
The PDSN shall use the flow mapping information if the
RAN-directed FLOW_ID-to-A10 connection mapping is received from the currently serving RAN and non-specific
TFTs are available from the mobile. Otherwise, the PDSN shall use the flow mapping information in the specific TFTs if available. If no mapping information is available from the mobile or the new RAN upon the inter-technology handoff, the
PDSN shall send all IP packets to the auxiliary A10 connection that carries the Reservation Label 0xFe if any; otherwise the PDSN shall send all packets to the main A10 connection.
Comment - If the handoff is from cmda2000 1x to HRPD, what is the use of specific TFTs? These are not used by HRPD devices, according to section 3.2.1 above.
Change to:
ROHC shall not be used for the auxiliary service connection that carries the Reservation Label 0xfe.

Cisco 4
Cisco 4
3.2.1.1 9 34-36 T/E
3.2.1.2 9 40-42 T
If an incoming forward packet does not match any packet filter within the corresponding TFT(s), the PDSN shall send the IP packet to the auxiliary A10 connection that carries the
Reservation Label 0xfe if any; otherwise the PDSN shall send the packets over the main A10.
Comment - What is the practical difference in usage between flow 0xff and flow 0xfe? It needs to be much clearer, either directly stated or by reference to some other specification.
3.2.1.2 Reverse Traffic Processing
When a packet arrives at the PDSN from the RAN, the source
IP address is checked to determine which TFT should be consulted. The PDSN searches for a packet filter match among all the packet filters in the TFTs belonging to the source IP address.
Comment - What happens for devices with private IP addresses? Is that covered by this scenario? Should it be keyed by something in addition to source IP address?

Cisco 4
Cisco 4
3.2.2 11 1-2 T
3.3 15 22-23 T
In the Forward Direction, if the PDSN receives any packet that matches a deactivated flow, the PDSN shall send the packet over the corresponding A10 connection.
Comment - Why is this done? Does it cater for a race condition?
Passing of verbose authorized QoS parameters in the RADIUS
Access-Accept is not supported in this release.
Comment - Can the PDSN use verbose mode when sending the local QoS profile settings to the RAN? This line needs some explanation added and probably references to appendix.
It is not at all clear how Verbose Authorized QoS parameters from Radius would make their way to the RAN. Is this defined in the HRPD A11 specification?

Cisco 4
Cisco 4
B.1.1.1.
1
37 14-19 E
B.1.1.1.
1
31 6-9 E
Change to:
The Non-Specific bit. This bit indicates the type of
FLOW_ID-to-A10 connection mapping requested for the associated TFT. When set, it indicates that the FLOW_ID-to-
A10 connection mapping shall be indicated by the RAN in
A11 signaling. When the bit is not set, it indicates that the
FLOW_ID-to-A10 connection mapping will be dictated by the
MS. When set, the SR_ID field shall be set to 0 and the P bit shall be set to 1. For HRPD, the NS bit is always set to 1. If the D field is set to '01', the NS bit shall be set to '1'.
Change to:
The P (Persistency) bit is set to ‘1’ to indicate a request from the MS to keep the TFT even if the A10 connection is not established or disconnected at the PDSN or flow ID to A10 connection mapping information is not yet received at the
PDSN form the RAN. Otherwise, it shall be set to ‘0’. For
HRPD this bit shall always be set to '1'.