[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: Re: IKEv2: prepending four octets
From: Ravi <ravivsn () roc ! co ! in>
Date: 2003-03-26 14:07:15
[Download RAW message or body]
Hi,
May I know why ikev2 should listen on both 500 and 4500.?What purpose does
it solve? In my view, we are complicating the protocol and implementation by doing
this.
If both IKEv1 and IKEv2 exist (most probably they exist as separate processes
or tasks and it is easy if we let IKEv1 and V2 exist separately), ikev1 can listen
on port 500 and ikev2 listen on 4500.
On the initiating side, if it has both v1 and v2, first it can try contacting the
responder with port 4500 i.e. IKEv2. If it does not get response in certain
duration, it can assume that IKEV2 is not supported by the responder and it can
fallback onto the ikev1 which sends packets onto port 500.
Also implementation wise it makes it easy and ikev1 and ikev2 can come from
two different vendors and typically TCP/IP stacks don't allow two sockets
listening on same port.
Francis Dupont wrote:
> In your previous mail you wrote:
>
> I think that we should at least agree that a peer that only works with port
> 4500 such as Ravi describes should interoperate with all IKEv2
> implementations.
>
>=> I agree.
>
> IOW an IKEv2 implementation must not assume that peers start the
> negotiations on port 500.
>
>=> I agree.
>
> Coding a Remote Access client like that is
> acceptable, since clients always initiate the first IKE negotiation.
> Gateways may initiate the negotiation on port 4500 when working with IKEv2
> peers (in fact, this could be a recommendation at the SHOULD level), but
> they SHOULD also listen on port 500.
>
>=> I believe we should give at least a MAY to initiate over 500 and 4500,
>perhaps with a SHOULD for port 4500 if one knows there is a NAT and a SHOULD
>for port 500 if one knows there is no NAT. In fact, this is more in the
>scope of a BCP. About listening, I am in favor of a MUST for both 500
>and 4500.
>
>Regards
>
>Francis.Dupont@enst-bretagne.fr
>
>
>
--
The views presented in this mail are completely mine. The company is not
responsible for whatsoever.
------------------------------------------------------------------------
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184
ROC home page <http://www.roc.co.in>
[Attachment #3 (text/html)]
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Hi,
May I know why ikev2 should listen on both 500 and 4500.?What purpose does
it solve? In my view, we are complicating the protocol and implementation by doing
this.
If both IKEv1 and IKEv2 exist (most probably they exist as separate processes
or tasks and it is easy if we let IKEv1 and V2 exist separately), ikev1 can listen
on port 500 and ikev2 listen on 4500.
On the initiating side, if it has both v1 and v2, first it can try contacting the
responder with port 4500 i.e. IKEv2. If it does not get response in certain
duration, it can assume that IKEV2 is not supported by the responder and it can
fallback onto the ikev1 which sends packets onto port 500.
Also implementation wise it makes it easy and ikev1 and ikev2 can come from
two different vendors and typically TCP/IP stacks don't allow two sockets
listening on same port.
Francis Dupont wrote:
> In your previous mail you wrote:
>
> I think that we should at least agree that a peer that only works with port
> 4500 such as Ravi describes should interoperate with all IKEv2
> implementations.
>
>=> I agree.
>
> IOW an IKEv2 implementation must not assume that peers start the
> negotiations on port 500.
>
>=> I agree.
>
> Coding a Remote Access client like that is
> acceptable, since clients always initiate the first IKE negotiation.
> Gateways may initiate the negotiation on port 4500 when working with IKEv2
> peers (in fact, this could be a recommendation at the SHOULD level), but
> they SHOULD also listen on port 500.
>
>=> I believe we should give at least a MAY to initiate over 500 and 4500,
>perhaps with a SHOULD for port 4500 if one knows there is a NAT and a SHOULD
>for port 500 if one knows there is no NAT. In fact, this is more in the
>scope of a BCP. About listening, I am in favor of a MUST for both 500
>and 4500.
>
>Regards
>
><mailto:Francis.Dupont@enst-bretagne.fr>Francis.Dupont@enst-bretagne.fr
>
>
--
The views presented in this mail are completely mine. The company is not responsible for whatsoever.
----------
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184
<http://www.roc.co.in>ROC home page
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic