[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bidding down attach on NAT-T
In your previous mail you wrote:
Francis Dupont <Francis.Dupont@enst-bretagne.fr> writes:
> => I believe you missed the fact I didn't try to make NAT traversal
> secure (I clearly wrote I believe it is near impossible): you are
> in my side, i.e., you consider that NAT traversal has an untrackable
> security issue with attackers which behave like NATs.
While I agree that peers should not use NAT-T if there is no NAT
between them,
=> fine, we agree at 100%.
I do think that NAT-T support should be required.
=> I have no objection but:
- configuration must have a knob to disable NAT-T support
- NAT detection must be secure.
You never know when there will be a NAT between you and your peer.
=> I agree but there are some cases where you don't want to support
a NAT between you and your peer.
Note that you CAN securely detect a NAT (and I consider a pseudo-NAT
to be equivalent to a NAT in this sense) because the IKE messages are
secured.
=> yes but the current draft does the NAT detection in the only unsecured
IKE messages, i.e, too soon!
So the only real attack is some router performing NAT on you
-- but that router could just as easily drop your packets too, so I
don't think this is a credible threat.
=> this should be the only real attack!
Personally, I feel that being able to use IPsec through a NAT is more
important than worrying about some router dropping your packets or
trying to re-NAT you.
=> I agree but I'd like to have NAT traversal active only when I know
it is possible to get a NAT on the path (i.e., a disable knob in the
config) and when there really is a NAT on the path (i.e., secure the
NAT detection).
Please read the NAT-DETECTION-*-IP stuff and say whether you are happy
with it (I am *not*)?
Thanks
Francis.Dupont@enst-bretagne.fr