Re: [IPsec] Issue #93: Next header value in tunnel mode for WESP
Hi Ken, It seems to me this field is more trouble than it's worth. We are assuming that the hardware will be enforcing a very simplistic security policy (don't care if it's Tunnel or Transport, don't care if it's a TCP SYN or not etc.) and that the hardware is unable to perform anything more than extremely basic packet parsing. Both assumptions may well be incorrect. And the cost is in complicating the protocol and the endpoint implementations. Thanks, Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Grewal, Ken > Sent: Thursday, April 30, 2009 23:39 > To: ipsec@ietf.org > Subject: [IPsec] Issue #93: Next header value in tunnel mode for WESP > > All, > As we prepare to submit the next revision of the WESP draft, we wanted to > get some discussion / feedback on some open ticket items. > > Issue #93: Next Header field to provide the value for the tunneled packet > if > using tunnel mode > > In the current traffic visibility draft, we indicate that the next header > value in the WESP header is equal to the next header value in the ESP > trailer. > Charlie Kaufman suggested that middle boxes may not want to differentiate > between tunnel / transport mode and just get to the payload. > i.e. consider providing the tunneled protocol value in WESP next header > field in the > case of tunnel mode and the WESP offset points to the tunneled payload > > Pros: easier parsing for intermediary devices > Cons: lose consistency between next header in WESP and in ESP trailer - > any > security concerns? > > Comments / opinions appreciated... > > Thanks, > - Ken > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Reopening issue #12
At 2:18 PM +0300 4/29/09, Tero Kivinen wrote: ... In most case I would not expect Bob to create the old SA that way at all, as it would require it to combine two SPD rules together when accepting such entry. As the SPD entries are ordered list that would mean it was combining two entries which had different locations in the list, and I am not sure if combining two SPD entries when creating SA is actually allowed by the RFC4301. 4301 does not have any notion of "combining" SPD entries. As you note, the SPD is ordered, so whichever SPD entry matches and is encountered first is used. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] A couple more issues
Hi, I will now open a few more IKEv2-bis issues that came up recently. Please reply within the next week, and if we have time, we may discuss some of them tomorrow. Did you notice we are now down to 22 open issues, out of 71? We are definitely getting there! Thanks, Yaron smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Issue #57: Clarify D-H transform
Yaron: 3.3.2: there is no explanation here or elsewhere that the D-H transform for ESP and AH is used for PFS. Paul (off list): Not done. I don't think it belongs in 3.3.2, and I also don't agree that the transform is "the D-H transform for ESP and AH is used for PFS"; that's an oversimplification. Yaron: I will settle for 1.3.1, and/or 1.3.3. smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Issue #58: Access control: add ref to IPsec architecture
Yaron:
3.5: this section is extremely liberal on what access control policies
people can implement, but that's too late to change now. However, we CAN at
least add a reference to RFC 4301, Sec. 4.4.3.1 (as was done in RFC 4945,
pki4ipsec).
Paul: Not done, take to the list.
Yaron: I propose to add after this noncommittal paragraph:
The Identification Payloads, denoted IDi and IDr in this memo, allow
peers to assert an identity to one another. This identity may be
used for policy lookup, but does not necessarily have to match
anything in the CERT payload; both fields may be used by an
implementation to perform access control decisions. {{ Clarif-7.1 }}
When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr
payloads, IKEv2 does not require this address to match the address in
the IP header of IKEv2 packets, or anything in the TSi/TSr payloads.
The contents of IDi/IDr is used purely to fetch the policy and
authentication data related to the other party.
The following new text, adapted from RFC 4945:
The Peer Authorization Database (PAD) as described in RFC 4301 [XX]
describes the use of the ID payload in IKEv2 and provides a formal model for
the binding of identity to policy in addition to providing services that
deal more specifically with the details of policy enforcement. The PAD is
intended to provide a link between the SPD and the IKE security association
management. See RFC 4301 [14], Section 4.4.3 for more details.
smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Issue #9: Notification when creation of CHILD_SA fails
Tero:
> same IP address. The initiator begins negotiation of a CHILD_SA
> using the SAi2 payload. The final fields (starting with SAi2) are
> described in the description of the CREATE_CHILD_SA exchange.
>
> <-- HDR, SK {IDr, [CERT,] AUTH,
> SAr2, TSi, TSr}
>
> The responder asserts its identity with the IDr payload, optionally
> sends one or more certificates (again with the certificate containing
> the public key used to verify AUTH listed first), authenticates its
> identity and protects the integrity of the second message with the
> AUTH payload, and completes negotiation of a CHILD_SA with the
> additional fields described below in the CREATE_CHILD_SA exchange.
>
> The recipients of messages 3 and 4 MUST verify that all signatures
> and MACs are computed correctly and that the names in the ID payloads
> correspond to the keys used to generate the AUTH payload.
>
> {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange
> fails for some reason, the IKE_SA is still created as usual. The
> list of responses in the IKE_AUTH exchange that do not prevent an
> IKE_SA from being set up include at least the following:
> NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
> INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
In the case of the that kind of failure the return packet will then be
without the SAr2, Tsi, and TSr, i.e.:
<-- HDR, SK {IDr, [CERT,] AUTH,
N(error_for_child_sa)}
If the authentication fails in such ways that the entries cannot
create IKE SA (authentication failure or similar), then the response
will be unencrypted, unauthenticated notify. There is no point of
sending the notify encrypted and integrity protected, as it is not
authenticated (as initiator and responder have not yet verified the
AUTH payloads):
<-- HDR, N(error_for_ike_sa)
The initiator receiving such reply MUST NOT immediately stop the SA
creation, but it should still retransmit the message few times, in
case that error notify was forgery and the real responder will reply
with valid reply. It can use the recipient of such message as a hint
to tell that authentication failed, thus it can shorten the
retransmission timers from few minutes down to few tens of seconds.
Paul:
The first part (don't nuke the IKE SA) is resolved, but the second part
(should the error message be encrypted) is still an open issue.
Yaron:
And then we had a long discussion (see e.g.
http://www.ietf.org/mail-archive/web/ipsec/current/msg03783.html) but it was
never resolved.
smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Issue #26: Missing treatment of error cases
Tero:
[2.21:]
> such a message (and also a network message like ICMP destination
> unreachable) as a hint that there might be problems with SAs to that
> IP address and should initiate a liveness test for any such IKE_SA.
> An implementation SHOULD limit the frequency of such tests to avoid
> being tricked into participating in a denial of service attack.
>
> A node receiving a suspicious message from an IP address with which
> it has an IKE_SA MAY send an IKE Notify payload in an IKE
> INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The
> recipient MUST NOT change the state of any SAs as a result, but may
> wish to audit the event to aid in diagnosing malfunctions. A node
> MUST limit the rate at which it will send messages in response to
> unprotected messages.
We should also extend this section and include at least following
cases:
- Errors happening before authentication
- Errors in the IPsec SA creation on IKE_AUTH
- Describe which errors are so fatal that they cause the whole IKE
SA to destroyed.
Paul indicated he's not convinced any of these new cases are needed.
Proposed new text would be welcome.
smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
