[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