[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SHIM6 Working Group Last Call on draft-ietf-shim6-proto-04.txt



Hi,

The Working Group Last Call for draft-ietf-shim6-proto-04.txt has concluded.

There has been one review report posted during this last call period (thanks Pekka) and one response (thanks Marcelo)

I'd like to ensure that we have clear consensus from the Working Group on the outcomes of this Last Call.

The points raised in the review are attached to this posting in summary form.

There are a number of points where the reviewer is invited to send text - a two week period (ending 14 May) is proposed for this.

On the basis of this WG Last Call a new draft of the document, addressing those points as noted below, is requested

regards,

  Geoff

----------- WG Last Call Review Comments ----------------------------------------


1) On IP multicast: it's not clear whether the text only applies to Any-Source-Multicast, rather than also to SSM.

   Comment:
Section 1.4 includes the text:: "In summary, IP multicast will not need the shim to remap the IP addresses"

    Conclusion:
It appears that the text in the draft, saying that the shim should not be applied to multicast addresses, applies to ASN as well as SSM.

    Recommendation:
    No further revisions to the document are required for this.


2) carrying the context tag opens the avenue for time-shifting attacks (e.g., data insertion into a session) after an attacker has moved from on-path to off-path ?

   Comment:
Marcelo has responded: "I would argue that it is probably easier to try to send packets with the spoofed source address than trying to intercept one of the shim6 establishment packets and then move away and inject packets in an ongoing communication. Especially, considering that those packets are likely to be discarded by higher layers, since they do not belong to any established communication. My perception of this is that the threat is similar to the current situation, if not less. Note that this could be easily solved by checking that the source locator is included in Ls(peer) but this has several difficulties in its own in the protocol functioning, and it doesn't seem to be worthy imho"

    Conclusion:
No further WG comment has been noted on this topic. Marcelo's comment indicates that no change to the draft is proposed

    Recommendation:
    No further revisions to the document are required for this.


3) The spec IMHO needs to say more about application framing impacts, as a result of adding the shim to some packets (well, we have been rather vague about this in the past, RFC4038 sec 5.4.2). TCP-like protocols are not a big problem because the stack can just adjust to whatever value is appropriate, but protocol such as UDP where the user needs to specify this are trickier. You should probably describe the required modifications to the implementations fragmentation handling code.

  Comment:
  There has been no further comment on this

  Conclusion
The reviewer is proposing a new section (11.2) to address fragmentation handling code

  Recommendation
The reviewer is requested to send proposed text of a section 11.2 of the draft to the Working Group for consideration. The document will be held for a further two (2) week awaiting this text.


4) There seem to be a number of minor attacks, and/or non-issues or residual threats which might be good to spell out better in the security considerations sections.

4.1) The only hash input that an attacker could not affect is the secret value, and even that is static. As the responder nonce is basically incremented based on the shim exchanges of the responder, the attacker can predict that as well. [...] That said, both of these issues may be no-op's because the value of the information protected is not very high. But these considerations should be spelled out.

  Comment:
Marcelo has responded: "rather than the information protected is not very high, i would say that it would be easier for the attacker to actually send the I1 messages and get new validators from the peer, rather than doing all this work [...] Agree, i guess we could also mention that the secret value could also be changed from once in a while making this attractive this attack, since the secret obtained would only be valid for a limited lifetime". There has been no further WG comment on this.

  Conclusion
The reviewer is proposing additional material to be included in the Security Considerations Section . The document will be held for a further two (2) week awaiting this text.

  Recommendation
The reviewer and document authors are requested to send proposed text of a section 11.2 of the draft to the Working Group for consideration. The document will be held for a further two (2) week awaiting this text.


4.2) what about the scenario where the initiator wishes to establish shim6 sessions when the other party isn't (yet) willing to do so? (Think about large content providers.) What are the graceful mechanisms to achieve this?

  Comment:
Marcelo has responded that this is not felt to be a security concern and that the I1 messages will be dropped by the other party. There has been no further WG comment on this.

    Recommendation:
    No further revisions to the document are required for this.

4.3) you really don't need the 4-way handshake under normal circumstances

    Comment:
Marcelo has noted that at the Interim SHIM6 meeting (October 2005), the proposal was to leave the 4 way handshake in the base spec and allow future extensions of the shim6 protocol for supporting this.

    Recommendation:
No further revisions to the document are required for this. The reviewer may propose to the Working Group via a draft submission an extension to the SHIM6 protocol for supporting a simpler I2 - R2 message exchange.

4.4) 47-bit context tags are the most troublesome issue to me. You should be more explicit what the effects of guessing (or knowing, from being on the path) the tag are, 'cause disruption' is a bit vague.

  Comment:
  Marcelo has proposed text along the lines of
"In particular, it would be possible for an attacker that once was on the path to send a payload message that is protected by the context tag. This means that the attacker can insert data packet inside an established communication. This has the same effect of sending packets with spoofed source address, right? Currently the only defense against this is ingress filtering, which may or may not be deployed. With the shim solution, the attacker needs to be on path and catch at least one of the packets that carry to context tag. Then it can leave the path and he will be able to inject packets that the shim layer will translate into the proper source address. I would argue that it is probably easier to try to send packets with the spoofed source address than trying to intercept one of the shim6 establishment packets and then move away and inject packets in an ongoing communication. Especially, considering that those packets are likely to be discarded by higher layers, since they do not belong to any established communication. My perception of this is that the threat is similar to the current situation, if not less. Note that this could be easily solved by checking that the source locator is included in Ls(peer) but this has several difficulties in its own in the protocol functioning, and it doesn't seem to be worthy imho"

  Recommendation:
The draft be revised to include this text in the Security Considerations Section


5) isn't there any timeout for contexts in ESTABLISHED state..? Does it stay there forever?"


    Comment:
Marcelo pointed out that this was covered in Section 9. No further WG comment has been made

    Recommendation:
    No further revisions to the document are required for this.


6) How do you define a recent Responder Nonce

    Comment:
Marcelo has responded: "this is also up to the implementations, but are you suggesting we provide some guidance about the lifetime of a responder nonce? like a maximum nonce lifetime or similar?" There has been no further WG comment.

    Recommendation:
    No further revisions to the document are required for this.


7) you should probably apply the same policy for certain other ICMP errors, at least type 1 code 1 "Communication with destination administratively prohibited", implying the protocol may be filtered at the firewall.

  Comment:
Marcelo has agreed with this suggestion for adding type 1 code 1 in addition to type 4, code 1

     Recommendation:
     Marcelo to edit the draft to reflect this change


8) Next Header: NO_NXT_HDR (59). "I'd make this 'Normally...' [when referring to options defined for this message] or the like, so that it would be clearer that it might be OK for future extensions (if any) to also put in some other value if they wanted to.

    Comment:
Allowing for unspecified 'other values' appears to be unwise in a standards specification

    Recommendation:
    No further revisions to the document are required for this.

9) Do you already specify somehow how you will treat yet-to-be-specified options? How do you parse the options that are not on the lists?

    Comment:
Marcelo wrote in response: "well, all the options have to have the format defined in section 5.14 whcih is basically a TLV format. In addition, it contains the C flag, that defines whether the option is criticial or not and if it must be recognized. what do you think that something is missing?" There has been no further WG comment on this

    Recommendation:
    No further revisions to the document are required for this.

10) I think this specification of padding adding is sub-optimal:

   Comment:
    There has been no WG comment on this observation

    Recommendation:
    No further revisions to the document are required for this.

11) in Normal context establishment, the responder is noted to stay IDLE folloing receipt of an R1 message. The question has been raised: how can the responder stay idle? it needs to remember _something_", so maybe a forward pointer to the security discussion (i.e., a global secret value) could be useful.

    Comment:
Marcelo has agreed to this suggestion of a forward pointer in the text to the security discussion

     Recommendation:
     Marcelo to edit the draft to reflect this change


12) The text notes that it is assumed that all the incoming packets that trigger the generation of an R1bis message contain a locator pair (in the address fields of the IPv6 header) and a Context Tag.. The reviewer suggest a rewording to the effect of "The locator pair is extracted from the source and destination IP addresses"

    Comment:
Marcelo has noted that: "well, this is in the case that new message formats are defined. We are assuming that they will contain the context tag. In this case, if they don't contain the context tag, it won't be possible to properly generate the R1bis packet."

    Recommendation:
    No further revisions to the document are required for this.

13) The CGA signature options is only applicable w/ new locators when you use non-HBA CGA addresses, right?

   Comment:
Marcel has noted: "yes, but it would be somehow strange to add new locators if you use HBAs, right? i mean, if you use HBAs the locator set is static. You could just include a subset on the HBA set in the locator set option initially exchanged and later on add new locators of the set, i guess, but i am not sure if this makes much sense, but we could add a clarification about this point if you think it would be useful". There has been no further WG comment on this suggestion


    Recommendation:
    No further revisions to the document are required for this.

14) the specification should suggest values for retransmission timeout and a value for I1_RETRIES_MAX

    Comment:
    Marcelo has aghreed with this comment

     Recommendation:
     Marcelo to edit the draft to reflect this change


15) Editoral suggestions

    Recommendation
     Marcelo to edit the draft to reflect changes as appropriate