On Fri, 10 Jan 2014, Valery Smyslov wrote:
1) Use of IDs
I don't think we should allow any IDs, as there could be conflicts with
other non-anonymous connections. Or possibly a way to detect which
non-anonymous IDs are accepted at the remote. I was leaning towards
mandating the ID to be "anonymous" to make it extremely clear that this
is an anonymous connection.
I think that using NULL Auth method clearly identifies
anonymous users and allows to distingush them from regular ones.
Adding special "anonymous" ID here seems to be superfluous.
Than you should stick to that and not send any IDs whatsoever.
to make errors in code. Second, as Yaron pointed out, IDs
may still be useful for upper level and sometimes even
could be verified via out-of-band means.
I am strongly against channel bindings, connection latching, or connection
reconfiguration-promotions. Nice good complicated ideas, but they have
failed with BTNS already. If you want access to a non-anonymously shared
resource, setup a proper authenticated IPsec connection.
So, I think that it's better to follow Occam's razor principle here
and not to add new ID type, as all that it could tell to the peer
is already told by using NULL Auth method.
Ocam's razor would tell you not to send IDs if you don't plan to use
them or have the other end use them.
2) Endpoints
Your draft does not state anything about the traffic selectors. I think
it is important to specify it for only a single host-to-host connection
only. Deployments who want to protect a whole subnet can use similar
tricks to load balancers and capture port (4)500 and use the NAT-T
capability of IPsec. Allowing subnet-to-subnet is just too dangerous
because there are no verifiable claims yet about who owns what IP range.
Aren't these restrictions too narrow? I can imagine situation with
anonymous user access to protected network (some kind of DMZ).
Again, you are promoting anonymous IPsec to "somewhat restricted could
possibly allow non-anoymous IPsec" upgrades. Don't.
In this case we will have one-way authentication (server will be
authenticated, but user - not) and traffic selectors host-subnet.
I can agree with you that peer using NULL Auth must
represent single IP only, but it is not necessary that
both peers will use NULL Auth, one of them may
be fully authenticated,
The problem is a server vouching for any IP ranges. How do you find out?
What's the discovery mechanism? How can we prevent it from falsely
claiming to give it precious traffic (like 127.0.0.1 or 8.8.8.8). The
initiator knows what IP it was trying to connect to. So to me, it should
be limited to that IP only.
I'll agree we might be able to do this work in another draft. But at
least it should go into the security consideration section.
3) Mode
I would like to only support tunnel mode and not transport mode, due to
the interaction with NATs - particularly multiple endpoints behind the
Why? Transport mode ESP has no issues with NAT, has it?
Yes it does, when multiple clients behind the same NAT router try to
connect to the same remote IPsec gateway.
4) Mandatory PFS
It should be mandatory to do PFS with an appropriate DH group.
Why should it be mandatory? Why can't it be left to local security policy?
Because null auth is already weak? Then again, I think PFS should be
made mandatory for all IPsec connections. I guess this could also move
into a separate OE draft.
It doesn't contradict to my proposal - roaming devices can put
anything in their identity or even make it empty - all at their discretion,
so they have all means to keep their anonymity.
But "at their discretion" means someone is going to make an
authentication decision based on it. It's dangerous. Instead of
sprinkling the draft with "SHOULD NOT use ID" and "MUST NOT use ID",
we should simply not give them the option for making such bad mistakes.
Most of your concerns are related to OE use case. I don't think
that NULL Auth is limited to OE case only. User may have all
credentials to authenticate himself, but still prefer to anonymously
access some protected network to prevent traceability of his actions.
So use NULL AUTH with no IDs? I don't see the problem?
On the other hand, I can imagine situation, when user must be authenticated,
So don't use NULL AUTH, but a real AUTH with ID.
I don't think we disagree here? When you say "allow the ID to be used
for audit only" I think you are introducing a false sense of security.
That ID could be easilly forged making the audit log incorrect. The
audit log _should_ log no ID if presented with a forgable ID.
So, I think that it is worth to separate NULL Auth from OE stuff
and describe all OE related issues in a separate draft, that
will use NULL Auth as a mechanism to skip authentication.
Sure, but than I do really want the ID parts not sent for NULL AUTH.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
