Subject: RE: [rddp] Need some clarification on how to "locate the start of theFPDU unambiguously"

From: "Caitlin Bestler" <[email-masked]>
Date: Tue, 30 Nov 2004 06:07:23 -0800

Keep in mind that "CRC suppression" does not eliminate the field,
only generating it and checking it. 

So my reading has always been that when CRCs are "suppressed" 
that the CRC field is always "valid".

Given the scenarios identified for suppressing CRCs, when there
is equivalent protection from IPSEC or something else, I think
it is also clear that this was the intent.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Barry Reinhold
> Sent: Tuesday, November 30, 2004 4:49 AM
> To: [email-masked]; RDDP
> Subject: [rddp] Need some clarification on how to "locate the 
> start of theFPDU unambiguously"
> 
> If markers are being used is it mandatory to also be using CRCs?
> This question arises out of the requirements of clause 5.4:
> 
> Clause 5.4 of MPA states the following:
> 
> ============
> 
> An MPA receiver MUST first verify the FPDU before passing the ULPDU
>    to DDP.  To do this, the receiver MUST:
> 
> 
>    *   locate the start of the FPDU unambiguously,
> 
> 
>    *   verify its CRC (if CRC checking is enabled).
> 
> 
>    If the above conditions are true, the MPA receiver passes the ULPDU
>    to DDP.
> 
> 
>    To detect the start of the FPDU unambiguously one of the following
>    MUST be used:
> 
> 
>    1:  In an ordered TCP stream, the ULPDU Length field in the current
>        FPDU when FPDU has a valid CRC, can be used to identify the
>        beginning of the next FPDU.
> 
> 
>    2:  For receivers that support out of order reception of FPDUs (see
>        section 5.1 MPA Markers on page 16) a Marker can always be used
>        to locate the beginning of an FPDU (in FPDUs with valid CRCs).
>        Since the location of the marker is known in the octet stream
>        (sequence number space), the marker can always be found.
> 
> 
>    3:  Having found an FPDU by means of a Marker, following contiguous
>        FPDUs can be found by using the ULPDU Lengths (from FPDUs with
>        valid CRCs) to establish the next FPDU boundary.
> =======
> 
> If we have an out of order FPDU, and support markers, we use 
> the next available marker to recover stream sync. By item two 
> above, this requires that we validate the FPDU which has the 
> marker in it with a CRC.
> 
> Hence it appears that an implementation planning on using 
> markers must also require that CRCs be supported. Is this the intent?
> 
>  
> 
> Barry Reinhold
> Lamprey Networks
> [email-masked]
> (603) 868-8411
>  
> 
> 
> 
> 
> _______________________________________________
> rddp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rddp
> 

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

---

From: "Michael C. Cambria" <[email-masked]>
Date: Tue, 30 Nov 2004 09:51:45 -0500

> that the CRC field is always "valid".

This has been my assumption as well.

> it is also clear that this was the intent.

Since I'm on the subject of making assumptions explicit...

When IPsec is mentioned in this context, doesn't it specifically mean 
IPsec with Authentication (or Authentication & Encryption)?   IPsec with 
Encryption alone isn't a substitute for CRC32c.

This is also assuming that the IPsec SPD is setup to ensure that this 
policy will happen, e.g. there is no way for the remote peer to 
negotiate the security policy "down".

Regards,
MikeC

---

From: Sukanta ganguly <[email-masked]>
Date: Tue, 30 Nov 2004 07:20:54 -0800 (PST)

MikeC,
  IPSec with encryption will also attain the same
level of integrity and hence it should be OK.
Encryption based on IPSec is a much better mechanism
rather than just CRC32c.
   I am not sure what you mean by "negotiating the
policy down". Once the IPSec connection with the
remote pair is established that is your policy, which
is established at the time of connection setup.

SG

> negotiate the security policy "down".

__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail