On 02/12/2014 12:23 AM, Nicholas A. Bellinger wrote:
On Tue, 2014-02-11 at 19:10 +0530, Sumit Rai wrote:
Hi,
I am sending login PDU with CSG=Security Negotiation, T=0, NSG=2.
Note: We deliberately setting NSG to invalid value of 2.
Now, the Target is failing the login with 'Initiator Error
(miscellaneous error)'.
It's my understanding that since T bit is 0, NSG is reserved and invalid
NSG should not cause login to fail.
As per RFC "The next stage value is only valid when the T bit is 1;
otherwise, it is reserved."
"10.12.3. CSG and NSG
Through these fields, Current Stage (CSG) and Next Stage (NSG), the
Login negotiation requests and responses are associated with a
specific stage in the session (SecurityNegotiation,
LoginOperationalNegotiation, FullFeaturePhase) and may indicate the
next stage to which they want to move (see Chapter 5). The next
stage value is only valid when the T bit is 1; otherwise, it is
reserved.
The stage codes are:
- 0 - SecurityNegotiation
- 1 - LoginOperationalNegotiation
- 3 - FullFeaturePhase
All other codes are reserved."
Is this an expected behavior?
Yes. My original interpretation was that valid values for stage codes
are ignored when the transmit bit is not set. However, values such as
NSG=2 (eg: an illegal value) are always considered a protocol error,
regardless of transmit bit.
--nab
RFC states
"Any compliant sender MUST set all bits not defined and all reserved
fields to zero unless specified otherwise. Any compliant receiver
MUST ignore any bit not defined and all reserved fields unless
specified otherwise. Receipt of reserved code values in defined
fields MUST be reported as a protocol error."
It's my understanding that sending reserved code values (e.g. 2 in NSG
Field since all codes other than 0,1, 3 are reserved) in defined field
is considered an protocol error. But, according to RFC NSG is reserved
field when T=0 so target must ignore it.
Is my understanding correct?
Thanks,
Sumit Rai
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
